From: Nathan Chancellor <nathan@kernel.org> To: Masahiro Yamada <masahiroy@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-kbuild@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, llvm@lists.linux.dev, Conor Dooley <conor.dooley@microchip.com> Subject: Re: [PATCH] lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 Date: Mon, 3 Oct 2022 09:10:51 -0700 [thread overview] Message-ID: <YzsJi7sT54dJtvKw@dev-arch.thelio-3990X> (raw) In-Reply-To: <CAK7LNATqoW-3fmFZBAbPuKhdRn4UD_o8jthVsBanyYzFWpzSSA@mail.gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org> To: Masahiro Yamada <masahiroy@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-kbuild@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, llvm@lists.linux.dev, Conor Dooley <conor.dooley@microchip.com> Subject: Re: [PATCH] lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 Date: Mon, 3 Oct 2022 09:10:51 -0700 [thread overview] Message-ID: <YzsJi7sT54dJtvKw@dev-arch.thelio-3990X> (raw) In-Reply-To: <CAK7LNATqoW-3fmFZBAbPuKhdRn4UD_o8jthVsBanyYzFWpzSSA@mail.gmail.com> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-10-03 16:10 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-28 18:25 [PATCH] lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 Nathan Chancellor 2022-09-28 18:25 ` Nathan Chancellor 2022-09-28 21:13 ` Nick Desaulniers 2022-09-28 21:13 ` Nick Desaulniers 2022-09-28 21:36 ` Nathan Chancellor 2022-09-28 21:36 ` Nathan Chancellor 2022-09-28 21:53 ` Nick Desaulniers 2022-09-28 21:53 ` Nick Desaulniers 2022-10-02 17:59 ` Masahiro Yamada 2022-10-02 17:59 ` Masahiro Yamada 2022-10-02 18:47 ` Masahiro Yamada 2022-10-02 18:47 ` Masahiro Yamada 2022-10-03 16:10 ` Nathan Chancellor [this message] 2022-10-03 16:10 ` Nathan Chancellor
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YzsJi7sT54dJtvKw@dev-arch.thelio-3990X \ --to=nathan@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=conor.dooley@microchip.com \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=llvm@lists.linux.dev \ --cc=masahiroy@kernel.org \ --cc=ndesaulniers@google.com \ --cc=palmer@dabbelt.com \ --cc=patches@lists.linux.dev \ --cc=trix@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.