Linux: arm64 allyesconfig build failure with CONFIG_DYNAMIC_DEBUG_RELATIVE_POINTERS

[nathanchance]

After commit 9d9247d08d72 ("arm64: select DYNAMIC_DEBUG_RELATIVE_POINTERS") and the previous patches, the build explodes.

Build log: https://gist.githubusercontent.com/nathanchance/56deb988c4fc4eb9b450bec4d1484ede/raw/15fb7bf95c09107eb086b81ebdad00ff036e973b/gistfile1.txt

Bisect log:

git bisect log
git bisect start
# good: [12a54b150fb5b6c2f3da932dc0e665355f8a5a48] Merge tag 'nfsd-5.1-1' of git://linux-nfs.org/~bfields/linux
git bisect good 12a54b150fb5b6c2f3da932dc0e665355f8a5a48
# bad: [c392798a85ab955fa9385e84da1a4110d462b7f0] Add linux-next specific files for 20190424
git bisect bad c392798a85ab955fa9385e84da1a4110d462b7f0
# good: [cfcc68ba6c712a457f1ad32a9902193e7ce273ef] Merge remote-tracking branch 'crypto/master'
git bisect good cfcc68ba6c712a457f1ad32a9902193e7ce273ef
# good: [5eb319eaa3373dff941b926739901b5b80ce6ccc] Merge remote-tracking branch 'spi/for-next'
git bisect good 5eb319eaa3373dff941b926739901b5b80ce6ccc
# good: [64048ab2129c661f6faf71a390aadfea04fcb202] Merge remote-tracking branch 'staging/staging-next'
git bisect good 64048ab2129c661f6faf71a390aadfea04fcb202
# good: [d20f1135d063896ab7f9707abad1363974fc8da4] Merge remote-tracking branch 'coresight/next'
git bisect good d20f1135d063896ab7f9707abad1363974fc8da4
# bad: [7a71919c6d480d62f5246b4fe64f9c236c9ac44f] autofs: add description of ignore pseudo mount option
git bisect bad 7a71919c6d480d62f5246b4fe64f9c236c9ac44f
# good: [f8efa622bb611613305e76d5b9f2f14811a929c5] mm: use mm_zero_struct_page from SPARC on all 64b architectures
git bisect good f8efa622bb611613305e76d5b9f2f14811a929c5
# good: [d21718f348b21d1b69a2954d9b32cd1fa8db1396] mm-move-buddy-list-manipulations-into-helpers-fix2
git bisect good d21718f348b21d1b69a2954d9b32cd1fa8db1396
# bad: [baa09d557536cf1fd951cf811e039d466da3d5ef] lib/sort: use more efficient bottom-up heapsort variant
git bisect bad baa09d557536cf1fd951cf811e039d466da3d5ef
# good: [6167b1f85d97daec7e3b863b5a5ee2e4c88699c6] linux/device.h: use unique identifier for each struct _ddebug
git bisect good 6167b1f85d97daec7e3b863b5a5ee2e4c88699c6
# bad: [9d9247d08d7269d9772bd5c3af9e642a3c1bd8bc] arm64: select DYNAMIC_DEBUG_RELATIVE_POINTERS
git bisect bad 9d9247d08d7269d9772bd5c3af9e642a3c1bd8bc
# good: [999b10c70f31c81345ca76381e2ed481d1b79704] lib/dynamic_debug.c: drop use of bitfields in struct _ddebug
git bisect good 999b10c70f31c81345ca76381e2ed481d1b79704
# good: [0adc0fccea2301a923f0c5db0120851b7f2805b5] lib/dynamic_debug.c: add asm-generic implementation for DYNAMIC_DEBUG_RELATIVE_POINTERS
git bisect good 0adc0fccea2301a923f0c5db0120851b7f2805b5
# good: [6c5c9318c1d396a0274992c923127e2e20b5b08a] x86_64: select DYNAMIC_DEBUG_RELATIVE_POINTERS
git bisect good 6c5c9318c1d396a0274992c923127e2e20b5b08a
# first bad commit: [9d9247d08d7269d9772bd5c3af9e642a3c1bd8bc] arm64: select DYNAMIC_DEBUG_RELATIVE_POINTERS

[nickdesaulniers]

cc @Villemoes

[nickdesaulniers]

/home/nathan/cbl/linux-next/init/initramfs.c:477:3: error: invalid operand in inline asm: '.ifndef __UNIQUE_ID_ddebug18.pushsection __verbose,"aw".type __UNIQUE_ID_ddebug18, STT_OBJECT.size __UNIQUE_ID_ddebug18, ${5:c}1:__UNIQUE_ID_ddebug18:   .int ${0:c} - 1b /* _ddebug::modname_disp */    .int ${1:c} - 1b /* _ddebug::function_disp */   .int ${2:c} - 1b /* _ddebug::filename_disp */   .int ${3:c} - 1b /* _ddebug::format_disp */ .int ${4:c}      /* _ddebug::flags_lineno */    .org 1b+${5:c}.popsection.set __UNIQUE_ID_ddebug18.ddebug.once, ${6:c}.elseif __UNIQUE_ID_ddebug18.ddebug.once - ${6:c}.line 477 - 1.error "'__UNIQUE_ID_ddebug18' used as _ddebug identifier more than once".endif'

I think this is just another symptom of #449. Applying https://reviews.llvm.org/D60887 would confirm/deny.

[Villemoes]

Hm, yeah, it would be a bit too magical if that piece of asm not only worked across architectures, but also with assemblers other than gas. The trivial temporary fix is to append "if CC_IS_GCC" to the "select DYNAMIC_DEBUG_RELATIVE_POINTERS" statements, perhaps just for arm64 if it seems to work for x86-64 (does clang do ppc64 at all?)

[nickdesaulniers]

The trivial temporary fix

Or I could just land my LLVM patch (code reviewers taking their sweet time 🤡 )

does clang do ppc64 at all?

Yes; see our CI and @shenki's talk

[nathanchance]

@nickdesaulniers Applying https://reviews.llvm.org/D60887 resolves this, thank you for pointing that out :)

We'll still probably want to add a if CLANG_VERSION >= 90000 || CC_IS_GCC to the arm64 and ppc select statements once that patch has landed so the build doesn't break with earlier versions of clang.

[nickdesaulniers]

@Villemoes sent 2 patches to fix this up:

• https://lkml.org/lkml/2019/4/29/743: [PATCH 11/10] arm64: unbreak DYNAMIC_DEBUG=y build with clang
• https://lkml.org/lkml/2019/4/29/747: [PATCH 12/10] powerpc: unbreak DYNAMIC_DEBUG=y build with clang

[nickdesaulniers]

Also, it seems that the 0day folks are re-engaging, which is good.

[nathanchance]

This has been fixed by dropping the patchset from -next and fixing it in a newer version: https://lore.kernel.org/lkml/[email protected]/

Closing for now.