| Message ID | 20220928182523.3105953-1-nathan@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 | expand |
On Wed, Sep 28, 2022 at 11:25 AM Nathan Chancellor <nathan@kernel.org> wrote: > > When building with a RISC-V kernel with DWARF5 debug info using clang > and the GNU assembler, several instances of the following error appear: > > /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported > > Dumping the .s file reveals these .uleb128 directives come from > .debug_loc and .debug_ranges: > > .Ldebug_loc0: > .byte 4 # DW_LLE_offset_pair > .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset > .byte 1 # Loc expr size > .byte 90 # DW_OP_reg10 > .byte 0 # DW_LLE_end_of_list > > .Ldebug_ranges0: > .byte 4 # DW_RLE_offset_pair > .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset > .byte 4 # DW_RLE_offset_pair > .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset > .byte 0 # DW_RLE_end_of_list > > There is an outstanding binutils issue to support a non-constant operand > to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to > be any movement on it, due to concerns over how it would work with > linker relaxation. > > To avoid these build errors, prevent DWARF5 from being selected when > using clang and an assembler that does not have support for these symbol > deltas, which can be easily checked in Kconfig with as-instr plus the > small test program from the dwz test suite from the binutils issue. > > Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > Link: https://github.com/ClangBuiltLinux/linux/issues/1719 > Tested-by: Conor Dooley <conor.dooley@microchip.com> > Signed-off-by: Nathan Chancellor <nathan@kernel.org> > --- > lib/Kconfig.debug | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index d3e5f36bb01e..19de03ead2ed 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -231,6 +231,9 @@ config DEBUG_INFO > in the "Debug information" choice below, indicating that debug > information will be generated for build targets. > > +config AS_HAS_NON_CONST_LEB128 > + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) > + > choice > prompt "Debug information" > depends on DEBUG_KERNEL > @@ -277,6 +280,10 @@ config DEBUG_INFO_DWARF5 > bool "Generate DWARF Version 5 debuginfo" > select DEBUG_INFO > depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) > + # Clang is known to generate .{s,u}leb128 with symbol deltas with > + # DWARF5, which some targets may not support. > + # https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > + depends on !CC_IS_CLANG || AS_HAS_NON_CONST_LEB128 Reraising my concern from https://github.com/ClangBuiltLinux/linux/issues/1719#issuecomment-1258678969 We've put a fair amount of work into getting CC=clang LLVM_IAS=0 to work for DWARF v5 (both on the GNU binutils side, and Kbuild), I'd hate to see that effectively knee-capped because of an issue in GNU binutils that is only relevant for one architecture. I'd concede support for ARCH=riscv, but not for all other architectures, which this effectively does. > help > Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc > 5.0+ accepts the -gdwarf-5 flag but only had partial support for some > > base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff > -- > 2.37.3 > >
On Wed, Sep 28, 2022 at 02:13:47PM -0700, Nick Desaulniers wrote: > On Wed, Sep 28, 2022 at 11:25 AM Nathan Chancellor <nathan@kernel.org> wrote: > > > > When building with a RISC-V kernel with DWARF5 debug info using clang > > and the GNU assembler, several instances of the following error appear: > > > > /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported > > > > Dumping the .s file reveals these .uleb128 directives come from > > .debug_loc and .debug_ranges: > > > > .Ldebug_loc0: > > .byte 4 # DW_LLE_offset_pair > > .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset > > .byte 1 # Loc expr size > > .byte 90 # DW_OP_reg10 > > .byte 0 # DW_LLE_end_of_list > > > > .Ldebug_ranges0: > > .byte 4 # DW_RLE_offset_pair > > .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset > > .byte 4 # DW_RLE_offset_pair > > .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset > > .byte 0 # DW_RLE_end_of_list > > > > There is an outstanding binutils issue to support a non-constant operand > > to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to > > be any movement on it, due to concerns over how it would work with > > linker relaxation. > > > > To avoid these build errors, prevent DWARF5 from being selected when > > using clang and an assembler that does not have support for these symbol > > deltas, which can be easily checked in Kconfig with as-instr plus the > > small test program from the dwz test suite from the binutils issue. > > > > Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > > Link: https://github.com/ClangBuiltLinux/linux/issues/1719 > > Tested-by: Conor Dooley <conor.dooley@microchip.com> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org> > > --- > > lib/Kconfig.debug | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index d3e5f36bb01e..19de03ead2ed 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -231,6 +231,9 @@ config DEBUG_INFO > > in the "Debug information" choice below, indicating that debug > > information will be generated for build targets. > > > > +config AS_HAS_NON_CONST_LEB128 > > + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) > > + > > choice > > prompt "Debug information" > > depends on DEBUG_KERNEL > > @@ -277,6 +280,10 @@ config DEBUG_INFO_DWARF5 > > bool "Generate DWARF Version 5 debuginfo" > > select DEBUG_INFO > > depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) > > + # Clang is known to generate .{s,u}leb128 with symbol deltas with > > + # DWARF5, which some targets may not support. > > + # https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > > + depends on !CC_IS_CLANG || AS_HAS_NON_CONST_LEB128 > > Reraising my concern from > https://github.com/ClangBuiltLinux/linux/issues/1719#issuecomment-1258678969 Sorry, I thought I addressed your concern with my comment right below it but I probably should have worded it better. > We've put a fair amount of work into getting CC=clang LLVM_IAS=0 to > work for DWARF v5 (both on the GNU binutils side, and Kbuild), I'd > hate to see that effectively knee-capped because of an issue in GNU > binutils that is only relevant for one architecture. Sure, that is a completely reasonable concern. However... > I'd concede support for ARCH=riscv, but not for all other > architectures, which this effectively does. No, it does not, CONFIG_AS_HAS_NON_CONST_LEB128 can still be enabled when GNU as supports this construct for a particular architecture; as far as I can tell, RISC-V is the only one that doesn't. See the tests with ARCH=arm64 and ARCH=x86_64 compared with ARCH=riscv below. $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 LLVM_IAS=0 defconfig $ rg "CONFIG_AS_(IS|VERSION|HAS)" .config 9:CONFIG_AS_IS_GNU=y 10:CONFIG_AS_VERSION=23950 4750:CONFIG_AS_HAS_NON_CONST_LEB128=y $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 LLVM_IAS=0 defconfig $ rg "CONFIG_AS_(IS|VERSION|HAS)" .config 9:CONFIG_AS_IS_GNU=y 10:CONFIG_AS_VERSION=23950 442:CONFIG_AS_HAS_LDAPR=y 443:CONFIG_AS_HAS_LSE_ATOMICS=y 451:CONFIG_AS_HAS_ARMV8_2=y 452:CONFIG_AS_HAS_SHA3=y 465:CONFIG_AS_HAS_PAC=y 466:CONFIG_AS_HAS_CFI_NEGATE_RA_STATE=y 473:CONFIG_AS_HAS_ARMV8_4=y 480:CONFIG_AS_HAS_ARMV8_5=y 9719:CONFIG_AS_HAS_NON_CONST_LEB128=y $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- LLVM=1 LLVM_IAS=0 defconfig $ rg "CONFIG_AS_(IS|VERSION|HAS)" .config 9:CONFIG_AS_IS_GNU=y 10:CONFIG_AS_VERSION=23950 Cheers, Nathan
On Wed, Sep 28, 2022 at 2:36 PM Nathan Chancellor <nathan@kernel.org> wrote: > > On Wed, Sep 28, 2022 at 02:13:47PM -0700, Nick Desaulniers wrote: > > Reraising my concern from > > https://github.com/ClangBuiltLinux/linux/issues/1719#issuecomment-1258678969 > > Sorry, I thought I addressed your concern with my comment right below it > but I probably should have worded it better. No, I just missed your point about other architectures. > > We've put a fair amount of work into getting CC=clang LLVM_IAS=0 to > > work for DWARF v5 (both on the GNU binutils side, and Kbuild), I'd > > hate to see that effectively knee-capped because of an issue in GNU > > binutils that is only relevant for one architecture. > > Sure, that is a completely reasonable concern. However... > > > I'd concede support for ARCH=riscv, but not for all other > > architectures, which this effectively does. > > No, it does not, CONFIG_AS_HAS_NON_CONST_LEB128 can still be enabled > when GNU as supports this construct for a particular architecture; as > far as I can tell, RISC-V is the only one that doesn't. See the tests > with ARCH=arm64 and ARCH=x86_64 compared with ARCH=riscv below. Ah, sorry for the noise then. Thanks for the patch. Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
On Thu, Sep 29, 2022 at 6:53 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Wed, Sep 28, 2022 at 2:36 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > On Wed, Sep 28, 2022 at 02:13:47PM -0700, Nick Desaulniers wrote: > > > Reraising my concern from > > > https://github.com/ClangBuiltLinux/linux/issues/1719#issuecomment-1258678969 > > > > Sorry, I thought I addressed your concern with my comment right below it > > but I probably should have worded it better. > > No, I just missed your point about other architectures. > > > > We've put a fair amount of work into getting CC=clang LLVM_IAS=0 to > > > work for DWARF v5 (both on the GNU binutils side, and Kbuild), I'd > > > hate to see that effectively knee-capped because of an issue in GNU > > > binutils that is only relevant for one architecture. > > > > Sure, that is a completely reasonable concern. However... > > > > > I'd concede support for ARCH=riscv, but not for all other > > > architectures, which this effectively does. > > > > No, it does not, CONFIG_AS_HAS_NON_CONST_LEB128 can still be enabled > > when GNU as supports this construct for a particular architecture; as > > far as I can tell, RISC-V is the only one that doesn't. See the tests > > with ARCH=arm64 and ARCH=x86_64 compared with ARCH=riscv below. > > Ah, sorry for the noise then. Thanks for the patch. > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > > -- > Thanks, > ~Nick Desaulniers This patch is incomplete. It looks like Clang 14 switched to DWARF v5 by default. I see the same errors for CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y masahiro@zoe:~/ref/linux$ clang --version | head -n1 Ubuntu clang version 14.0.0-1ubuntu1 masahiro@zoe:~/ref/linux$ grep DEBUG_INFO_DWARF .config CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_DWARF5 is not set masahiro@zoe:~/ref/linux$ make ARCH=riscv LLVM=1 LLVM_IAS=0 CROSS_COMPILE=riscv64-linux-gnu- -j24 CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CC arch/riscv/kernel/vdso/vgettimeofday.o /tmp/vgettimeofday-5997b4.s: Assembler messages: /tmp/vgettimeofday-5997b4.s:2698: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2699: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2705: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2706: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2712: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2713: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2719: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2720: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2726: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2727: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2731: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2732: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2736: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2737: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2743: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2744: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2748: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2749: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2755: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2756: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2760: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2761: Error: non-constant .uleb128 is not supported /tmp/vgettimeofday-5997b4.s:2765: Error: non-constant .uleb128 is not supported ...
On Thu, Sep 29, 2022 at 3:25 AM Nathan Chancellor <nathan@kernel.org> wrote: > > When building with a RISC-V kernel with DWARF5 debug info using clang > and the GNU assembler, several instances of the following error appear: > > /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported > > Dumping the .s file reveals these .uleb128 directives come from > .debug_loc and .debug_ranges: > > .Ldebug_loc0: > .byte 4 # DW_LLE_offset_pair > .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset > .byte 1 # Loc expr size > .byte 90 # DW_OP_reg10 > .byte 0 # DW_LLE_end_of_list > > .Ldebug_ranges0: > .byte 4 # DW_RLE_offset_pair > .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset > .byte 4 # DW_RLE_offset_pair > .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset > .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset > .byte 0 # DW_RLE_end_of_list > > There is an outstanding binutils issue to support a non-constant operand > to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to > be any movement on it, due to concerns over how it would work with > linker relaxation. > > To avoid these build errors, prevent DWARF5 from being selected when > using clang and an assembler that does not have support for these symbol > deltas, which can be easily checked in Kconfig with as-instr plus the > small test program from the dwz test suite from the binutils issue. > > Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > Link: https://github.com/ClangBuiltLinux/linux/issues/1719 > Tested-by: Conor Dooley <conor.dooley@microchip.com> > Signed-off-by: Nathan Chancellor <nathan@kernel.org> > --- > lib/Kconfig.debug | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index d3e5f36bb01e..19de03ead2ed 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -231,6 +231,9 @@ config DEBUG_INFO > in the "Debug information" choice below, indicating that debug > information will be generated for build targets. > > +config AS_HAS_NON_CONST_LEB128 > + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) > + > choice > prompt "Debug information" > depends on DEBUG_KERNEL > @@ -277,6 +280,10 @@ config DEBUG_INFO_DWARF5 > bool "Generate DWARF Version 5 debuginfo" > select DEBUG_INFO > depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) > + # Clang is known to generate .{s,u}leb128 with symbol deltas with > + # DWARF5, which some targets may not support. > + # https://sourceware.org/bugzilla/show_bug.cgi?id=27215 If you plan to patch both DWARF_TOOLCHAIN_DEFAULT and DWARF5, it will be cleaner to move this comment to AS_HAS_NON_CONST_LEB128. > + depends on !CC_IS_CLANG || AS_HAS_NON_CONST_LEB128 The condition "!CC_IS_CLANG" is repeated here. If you use the following patch as basic, https://lore.kernel.org/lkml/20221002181107.51286-2-masahiroy@kernel.org/T/#u you can write the code like this: !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_LEB128) Another big hammer solution is to give up Clang+GAS for CONFIG_DEBUG_INFO. If we go this way, this patch is unneeded, though. Thoughts?
On Mon, Oct 03, 2022 at 03:47:30AM +0900, Masahiro Yamada wrote: > On Thu, Sep 29, 2022 at 3:25 AM Nathan Chancellor <nathan@kernel.org> wrote: > > > > When building with a RISC-V kernel with DWARF5 debug info using clang > > and the GNU assembler, several instances of the following error appear: > > > > /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported > > > > Dumping the .s file reveals these .uleb128 directives come from > > .debug_loc and .debug_ranges: > > > > .Ldebug_loc0: > > .byte 4 # DW_LLE_offset_pair > > .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset > > .byte 1 # Loc expr size > > .byte 90 # DW_OP_reg10 > > .byte 0 # DW_LLE_end_of_list > > > > .Ldebug_ranges0: > > .byte 4 # DW_RLE_offset_pair > > .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset > > .byte 4 # DW_RLE_offset_pair > > .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset > > .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset > > .byte 0 # DW_RLE_end_of_list > > > > There is an outstanding binutils issue to support a non-constant operand > > to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to > > be any movement on it, due to concerns over how it would work with > > linker relaxation. > > > > To avoid these build errors, prevent DWARF5 from being selected when > > using clang and an assembler that does not have support for these symbol > > deltas, which can be easily checked in Kconfig with as-instr plus the > > small test program from the dwz test suite from the binutils issue. > > > > Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > > Link: https://github.com/ClangBuiltLinux/linux/issues/1719 > > Tested-by: Conor Dooley <conor.dooley@microchip.com> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org> > > --- > > lib/Kconfig.debug | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index d3e5f36bb01e..19de03ead2ed 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -231,6 +231,9 @@ config DEBUG_INFO > > in the "Debug information" choice below, indicating that debug > > information will be generated for build targets. > > > > +config AS_HAS_NON_CONST_LEB128 > > + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) > > + > > choice > > prompt "Debug information" > > depends on DEBUG_KERNEL > > @@ -277,6 +280,10 @@ config DEBUG_INFO_DWARF5 > > bool "Generate DWARF Version 5 debuginfo" > > select DEBUG_INFO > > depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) > > + # Clang is known to generate .{s,u}leb128 with symbol deltas with > > + # DWARF5, which some targets may not support. > > + # https://sourceware.org/bugzilla/show_bug.cgi?id=27215 > > If you plan to patch both DWARF_TOOLCHAIN_DEFAULT and DWARF5, > it will be cleaner to move this comment to AS_HAS_NON_CONST_LEB128. Sure, that sounds reasonable! I can base this change on the series that you recently sent: https://lore.kernel.org/20221002181107.51286-1-masahiroy@kernel.org/ > > + depends on !CC_IS_CLANG || AS_HAS_NON_CONST_LEB128 > > The condition "!CC_IS_CLANG" is repeated here. > > If you use the following patch as basic, > https://lore.kernel.org/lkml/20221002181107.51286-2-masahiroy@kernel.org/T/#u > > you can write the code like this: > > !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && > AS_HAS_NON_CONST_LEB128) Right, I had initially had something along this line but the length of the line bothered some folks in pre-review so I opted for a second line. With your clean ups, it seems reasonable to move it back to the original line. > Another big hammer solution is to give up Clang+GAS for CONFIG_DEBUG_INFO. > If we go this way, this patch is unneeded, though. > Thoughts? I think this is a simple enough solution to avoid that big hammer at the moment but if we continue to run into corner cases like this, that is certainly worth considering. Cheers, Nathan
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d3e5f36bb01e..19de03ead2ed 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -231,6 +231,9 @@ config DEBUG_INFO in the "Debug information" choice below, indicating that debug information will be generated for build targets. +config AS_HAS_NON_CONST_LEB128 + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) + choice prompt "Debug information" depends on DEBUG_KERNEL @@ -277,6 +280,10 @@ config DEBUG_INFO_DWARF5 bool "Generate DWARF Version 5 debuginfo" select DEBUG_INFO depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) + # Clang is known to generate .{s,u}leb128 with symbol deltas with + # DWARF5, which some targets may not support. + # https://sourceware.org/bugzilla/show_bug.cgi?id=27215 + depends on !CC_IS_CLANG || AS_HAS_NON_CONST_LEB128 help Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
When building with a RISC-V kernel with DWARF5 debug info using clang and the GNU assembler, several instances of the following error appear: /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported Dumping the .s file reveals these .uleb128 directives come from .debug_loc and .debug_ranges: .Ldebug_loc0: .byte 4 # DW_LLE_offset_pair .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset .byte 1 # Loc expr size .byte 90 # DW_OP_reg10 .byte 0 # DW_LLE_end_of_list .Ldebug_ranges0: .byte 4 # DW_RLE_offset_pair .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset .byte 4 # DW_RLE_offset_pair .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset .byte 0 # DW_RLE_end_of_list There is an outstanding binutils issue to support a non-constant operand to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to be any movement on it, due to concerns over how it would work with linker relaxation. To avoid these build errors, prevent DWARF5 from being selected when using clang and an assembler that does not have support for these symbol deltas, which can be easily checked in Kconfig with as-instr plus the small test program from the dwz test suite from the binutils issue. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Link: https://github.com/ClangBuiltLinux/linux/issues/1719 Tested-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> --- lib/Kconfig.debug | 7 +++++++ 1 file changed, 7 insertions(+) base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff