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 <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
---
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
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 11:25 AM Nathan Chancellor <[email protected]> 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 <[email protected]>
> Signed-off-by: Nathan Chancellor <[email protected]>
> ---
> 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
>
>
--
Thanks,
~Nick Desaulniers
On Wed, Sep 28, 2022 at 02:13:47PM -0700, Nick Desaulniers wrote:
> On Wed, Sep 28, 2022 at 11:25 AM Nathan Chancellor <[email protected]> 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 <[email protected]>
> > Signed-off-by: Nathan Chancellor <[email protected]>
> > ---
> > 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 <[email protected]> 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 <[email protected]>
--
Thanks,
~Nick Desaulniers
On Thu, Sep 29, 2022 at 6:53 AM Nick Desaulniers
<[email protected]> wrote:
>
> On Wed, Sep 28, 2022 at 2:36 PM Nathan Chancellor <[email protected]> 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 <[email protected]>
>
> --
> 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
...
--
Best Regards
Masahiro Yamada
On Thu, Sep 29, 2022 at 3:25 AM Nathan Chancellor <[email protected]> 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 <[email protected]>
> Signed-off-by: Nathan Chancellor <[email protected]>
> ---
> 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/[email protected]/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?
--
Best Regards
Masahiro Yamada
On Mon, Oct 03, 2022 at 03:47:30AM +0900, Masahiro Yamada wrote:
> On Thu, Sep 29, 2022 at 3:25 AM Nathan Chancellor <[email protected]> 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 <[email protected]>
> > Signed-off-by: Nathan Chancellor <[email protected]>
> > ---
> > 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/[email protected]/
> > + 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/[email protected]/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