[PATCH] Kbuild: implement support for DWARF5

[Nick Desaulniers]

DWARF5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support. Further -gdwarf-X where X is an unsupported value doesn't
produce an error in $(CC). GNU `as` only recently gained support for
specifying -gdwarf-5.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head -n 5 | grep version
or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2

Make CONFIG_DEBUG_INFO_DWARF4 part of a Kconfig choice to preserve
forward compatibility.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---
RFC because this patch is super half baked, but I'm looking for
feedback.

I would logically split this into a series of patches;
1. disable -Wa,gdwarf-2 for LLVM_IAS=1, see also
https://github.com/ClangBuiltLinux/linux/issues/716
https://github.com/ClangBuiltLinux/continuous-integration/blob/master/patches/llvm-all/linux-next/arm64/silence-dwarf2-warnings.patch
that way we can backport for improved LLVM_IAS support.
2. move CONFIG_DEBUG_INFO_DWARF4 to choice.
3. implement the rest on top.

I'm pretty sure GNU `as` only recently gained the ability to specify
-gdwarf-4 without erroring in binutils 2.35, so that part likely needs
to be fixed.

Makefile | 19 ++++++++++++++++---
include/asm-generic/vmlinux.lds.h | 6 +++++-
lib/Kconfig.debug | 29 +++++++++++++++++++++++++----
scripts/test_dwarf5_support.sh | 4 ++++
4 files changed, 50 insertions(+), 8 deletions(-)
create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index e71979882e4f..0862df5b1a24 100644
--- a/Makefile
+++ b/Makefile
@@ -828,10 +828,23 @@ else
DEBUG_CFLAGS += -g
endif

-KBUILD_AFLAGS += -Wa,-gdwarf-2
-
+DWARF_VERSION=2
ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS += -gdwarf-4
+DWARF_VERSION=4
+endif
+ifdef CONFIG_DEBUG_INFO_DWARF5
+DWARF_VERSION=5
+endif
+DEBUG_CFLAGS += -gdwarf-$(DWARF_VERSION)
+
+ifneq ($(DWARF_VERSION)$(LLVM_IAS),21)
+KBUILD_AFLAGS += -Wa,-gdwarf-$(DWARF_VERSION)
+endif
+
+ifdef CONFIG_CC_IS_CLANG
+ifneq ($(LLVM_IAS),1)
+KBUILD_CFLAGS += -Wa,-gdwarf-$(DWARF_VERSION)
+endif
endif

ifdef CONFIG_DEBUG_INFO_REDUCED
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index cd14444bf600..0382808ef9fe 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -828,7 +828,11 @@
.debug_types 0 : { *(.debug_types) } \
/* DWARF 5 */ \
.debug_macro 0 : { *(.debug_macro) } \
- .debug_addr 0 : { *(.debug_addr) }
+ .debug_addr 0 : { *(.debug_addr) } \
+ .debug_line_str 0 : { *(.debug_line_str) } \
+ .debug_loclists 0 : { *(.debug_loclists) } \
+ .debug_rnglists 0 : { *(.debug_rnglists) } \
+ .debug_str_offsets 0 : { *(.debug_str_offsets) }

/* Stabs debugging sections. */
#define STABS_DEBUG \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 537cf3c2937d..6b01f0e2dad8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,14 +256,35 @@ config DEBUG_INFO_SPLIT
to know about the .dwo files and include them.
Incompatible with older versions of ccache.

+choice
+prompt "DWARF version"
+ depends on DEBUG_INFO
+ default DEBUG_INFO_DWARF2
+ help
+ Which version of DWARF debug info to emit.
+
+config DEBUG_INFO_DWARF2
+ bool "Generate dwarf2 debuginfo"
+ help
+ Generate dwarf2 debug info.
+
config DEBUG_INFO_DWARF4
bool "Generate dwarf4 debuginfo"
depends on $(cc-option,-gdwarf-4)
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate dwarf4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+
+config DEBUG_INFO_DWARF5
+ bool "Generate dwarf5 debuginfo"
+ depends on DEBUG_INFO
+ depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
+ help
+ Genereate dwarf5 debug info. Requires binutils 2.35+, gcc 5.1+, and
+ gdb 8.0+.
+
+endchoice # "DWARF version"

config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
new file mode 100755
index 000000000000..82c0eea45845
--- /dev/null
+++ b/scripts/test_dwarf5_support.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+set -eu
+echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
--
2.29.0.rc1.297.gfa9743e501-goog

[Fangrui Song]

On 2020-10-21, 'Nick Desaulniers' via Clang Built Linux wrote:
>DWARF5 is the latest standard of the DWARF debug info format.
>
>Feature detection of DWARF5 is onerous, especially given that we've
>removed $(AS), so we must query $(CC) for DWARF5 assembler directive
>support. Further -gdwarf-X where X is an unsupported value doesn't
>produce an error in $(CC). GNU `as` only recently gained support for
>specifying -gdwarf-5.
>
>The DWARF version of a binary can be validated with:

To be more correct: this is just the version number of the .debug_info section.
Other sections can use different version numbers.
(For example, GNU as still does not support version 5 .debug_line)

Consider adding .debug_names for the accelerator table.
It is the DWARF v5 version of .debug_pub{names,types} (which are mentioned
a few lines above).

> /* Stabs debugging sections. */
> #define STABS_DEBUG \
>diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>index 537cf3c2937d..6b01f0e2dad8 100644
>--- a/lib/Kconfig.debug
>+++ b/lib/Kconfig.debug
>@@ -256,14 +256,35 @@ config DEBUG_INFO_SPLIT
> to know about the .dwo files and include them.
> Incompatible with older versions of ccache.
>
>+choice
>+prompt "DWARF version"
>+ depends on DEBUG_INFO
>+ default DEBUG_INFO_DWARF2
>+ help
>+ Which version of DWARF debug info to emit.
>+
>+config DEBUG_INFO_DWARF2
>+ bool "Generate dwarf2 debuginfo"
>+ help
>+ Generate dwarf2 debug info.

In documentation, a more official way to refer to the format is: DWARF v2.
(While "DWARF5" and "DWARF v5" are acceptable, the latter is preferred)
Ditto below.

>--
>You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201022012106.1875129-1-ndesaulniers%40google.com.

[Nick Desaulniers]

Hi Masahiro,
I plan to incorporate Fangrui's recommendation into a v2. Do you have
additional thoughts on changes I should make in v2? Have you had the
chance to test the patch? Should I split it into a series? What do
you think about the Kconfig `choice` changes?

--
Thanks,
~Nick Desaulniers

[Masahiro Yamada]

This is not a shell script.
You can add spaces around '='

> ifdef CONFIG_DEBUG_INFO_DWARF4
> -DEBUG_CFLAGS += -gdwarf-4
> +DWARF_VERSION=4
> +endif
> +ifdef CONFIG_DEBUG_INFO_DWARF5
> +DWARF_VERSION=5
> +endif

This might be a bit tricky, but you can do like this if you like:


dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF3) := 3
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5

DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)

Indentation for 'prompt'.


> + depends on DEBUG_INFO

Unneeded.

This block resides inside 'if DEBUG_INFO'



> + default DEBUG_INFO_DWARF2


This is unneeded because the first entry
is the default.

Please tell me how this script detects the dwarf-5 capability.


This script fails for GCC 10.


masahiro@grover:~/workspace/linux-kbuild$
./scripts/test_dwarf5_support.sh clang
masahiro@grover:~/workspace/linux-kbuild$ echo $?
0
masahiro@grover:~/workspace/linux-kbuild$
./scripts/test_dwarf5_support.sh gcc-10
{standard input}: Assembler messages:
{standard input}:1: Error: file number less than one
masahiro@grover:~/workspace/linux-kbuild$ echo $?
1




The manual says the fileno should be "a positive integer".


.file fileno filename

When emitting dwarf2 line number information .file assigns filenames
to the .debug_line file name table.
The fileno operand should be a unique positive integer to use as the
index of the entry in the table.
The filename operand is a C string literal.

The detail of filename indices is exposed to the user because the
filename table is shared with the
.debug_info section of the dwarf2 debugging information, and thus
the user must know the exact indices
that table entries will have.



So, I modified the script as follows:


masahiro@grover:~/workspace/linux-kbuild$ git diff
diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
index 82c0eea45845..8d7213e8e51f 100755
--- a/scripts/test_dwarf5_support.sh
+++ b/scripts/test_dwarf5_support.sh
@@ -1,4 +1,4 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
set -eu
-echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
+echo ".file 1 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -




masahiro@grover:~/workspace/linux-kbuild$ ./scripts/test_dwarf5_support.sh gcc
masahiro@grover:~/workspace/linux-kbuild$ echo $?
0



But, GCC 4.9 also passes this check.

masahiro@grover:~/workspace/linux-kbuild$
~/tools/aarch64-linaro-4.9/bin/aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

masahiro@grover:~/workspace/linux-kbuild$
./scripts/test_dwarf5_support.sh
~/tools/aarch64-linaro-4.9/bin/aarch64-linux-gnu-gcc
masahiro@grover:~/workspace/linux-kbuild$ echo $?
0






Some nit-pickings.


echo '.file 0 "asdf"'

... might look cleaner because you do not need to
use escaping inside the single-quotes.



'set -u' seems to have no effect because "$*"
is the only variable expansion in this script.


-u Treat unset variables and parameters other than
the special parameters "@" and
"*" as an error when performing parameter
expansion. If expansion is attempted
on an unset variable or parameter, the shell
prints an error message, and, if
not interactive, exits with a non-zero status.

> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201022012106.1875129-1-ndesaulniers%40google.com.

--
Best Regards

Masahiro Yamada

[Jakub Jelinek]

On Mon, Nov 02, 2020 at 11:20:41AM +0900, Masahiro Yamada wrote:
> > --- /dev/null
> > +++ b/scripts/test_dwarf5_support.sh
> > @@ -0,0 +1,4 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +set -eu
> > +echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
>
>
>
> Please tell me how this script detects the dwarf-5 capability.
>
>
> This script fails for GCC 10.

One thing is GCC DWARF-5 support, that is whether the compiler
will support -gdwarf-5 flag, and that support should be there from
GCC 7 onwards.

Another separate thing is whether the assembler does support
the -gdwarf-5 option (i.e. if you can compile assembler files
with -Wa,-gdwarf-5) for GNU as I think that is binutils 35.1,
i.e. very new); but only if you want to pass the -Wa,-gdwarf-5
only when compiling *.s and *.S files. That option is about whether
the assembler will emit DWARF5 or DWARF2 .debug_line.
It is fine to compile C sources with -gdwarf-5 and use DWARF2
.debug_line for assembler files if as doesn't support it.

Yet another thing is if you can pass -Wa,-gdwarf-5 even when
compiling C files. There are several bugs in that category that have been
fixed only in the last few days on binutils trunk, I'd suggest
just not to bother, GCC 11 will have proper test for fixed assembler
and will pass -gdwarf-5 to as when compiling even C sources with -gdwarf-5.
The reason is to get DWARF5 .debug_line (.debug_line is usually produced
by the assembler, not compiler, from .file/.loc directives).

Jakub

[Nick Desaulniers]

On Sun, Nov 1, 2020 at 6:21 PM Masahiro Yamada <masa...@kernel.org> wrote:
>
> On Thu, Oct 22, 2020 at 10:21 AM 'Nick Desaulniers' via Clang Built
> Linux <clang-bu...@googlegroups.com> wrote:
> >
> > diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> > new file mode 100755
> > index 000000000000..82c0eea45845
> > --- /dev/null
> > +++ b/scripts/test_dwarf5_support.sh
> > @@ -0,0 +1,4 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +set -eu
> > +echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
>
>
>
> Please tell me how this script detects the dwarf-5 capability.

Ah, sorry, I should have put more context. Specifically, I wrote this
patch initially back in May, but testing combinations of:
- GCC + GNU as
- Clang + GNU as
- Clang + LLVM_IAS
I hit a few snags in GNU as. I reported the issues, and they were
quickly fixed. The fixes shipped in binutils 2.35 (or 2.35.1 as Jakub
notes).
https://sourceware.org/bugzilla/show_bug.cgi?id=25611
https://sourceware.org/bugzilla/show_bug.cgi?id=25612
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 <-- .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25917

This script is doing feature detection of `.file 0` directives (which
is new in DWARF5) in the assembler and actively emitted by Clang. I'm
happy to add whatever other unit tests might be interesting for
detecting correct support for various features, if we find them to be
required, which I'd say `.file 0` certainly is.

Probably could test GCC + LLVM_IAS, too.

Hence we need to test compiler and assembler support; either may be lacking.

> This script fails for GCC 10.

What is your version of binutils? Less than 2.35 I suspect? If so,
then that's expected and the script is working as intended.

Thanks for your feedback, I'll try to get a v2 out this week
incorporating feedback from you, Fangrui, and Jakub.

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Mon, Nov 2, 2020 at 12:18 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Mon, Nov 02, 2020 at 11:20:41AM +0900, Masahiro Yamada wrote:
> > > --- /dev/null
> > > +++ b/scripts/test_dwarf5_support.sh
> > > @@ -0,0 +1,4 @@
> > > +#!/bin/sh
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +set -eu
> > > +echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
> >
> >
> >
> > Please tell me how this script detects the dwarf-5 capability.
> >
> >
> > This script fails for GCC 10.
>
> One thing is GCC DWARF-5 support, that is whether the compiler
> will support -gdwarf-5 flag, and that support should be there from
> GCC 7 onwards.

I should improve my Kconfig check; I don't actually have a test for
-gdwarf-5 for the compiler. In godbolt, it looks like -gdwarf-5
produces an error from GCC up until GCC 5.1. Does (5.1 < GCC < 7) not
produce DWARF5? Maybe there's a more specific test you had in mind?

>
> Another separate thing is whether the assembler does support
> the -gdwarf-5 option (i.e. if you can compile assembler files
> with -Wa,-gdwarf-5) for GNU as I think that is binutils 35.1,
> i.e. very new); but only if you want to pass the -Wa,-gdwarf-5
> only when compiling *.s and *.S files. That option is about whether
> the assembler will emit DWARF5 or DWARF2 .debug_line.
> It is fine to compile C sources with -gdwarf-5 and use DWARF2
> .debug_line for assembler files if as doesn't support it.
>
> Yet another thing is if you can pass -Wa,-gdwarf-5 even when
> compiling C files. There are several bugs in that category that have been
> fixed only in the last few days on binutils trunk, I'd suggest
> just not to bother, GCC 11 will have proper test for fixed assembler
> and will pass -gdwarf-5 to as when compiling even C sources with -gdwarf-5.

Do you have links? I would prefer to do feature detection rather than
version detection when possible. If the bug is so severe that we
think we should scuttle support for old versions, I'm ok with that,
but I want to be able to link to hard proof in a commit message so
that in 6 months when I forget why we made a certain decision, we have
historical record in the commit message/git blame.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Wed, Oct 21, 2020 at 6:44 PM Fangrui Song <mas...@google.com> wrote:
>
> On 2020-10-21, 'Nick Desaulniers' via Clang Built Linux wrote:
> >DWARF5 is the latest standard of the DWARF debug info format.
> >
> >Feature detection of DWARF5 is onerous, especially given that we've
> >removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> >support. Further -gdwarf-X where X is an unsupported value doesn't
> >produce an error in $(CC). GNU `as` only recently gained support for
> >specifying -gdwarf-5.
> >
> >The DWARF version of a binary can be validated with:
>
> To be more correct: this is just the version number of the .debug_info section.
> Other sections can use different version numbers.
> (For example, GNU as still does not support version 5 .debug_line)

How do you recommend we validate that then?

>
> >$ llvm-dwarfdump vmlinux | head -n 5 | grep version
> >or
> >$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

> >diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> >index cd14444bf600..0382808ef9fe 100644
> >--- a/include/asm-generic/vmlinux.lds.h
> >+++ b/include/asm-generic/vmlinux.lds.h
> >@@ -828,7 +828,11 @@
> > .debug_types 0 : { *(.debug_types) } \
> > /* DWARF 5 */ \
> > .debug_macro 0 : { *(.debug_macro) } \
> >- .debug_addr 0 : { *(.debug_addr) }
> >+ .debug_addr 0 : { *(.debug_addr) } \
> >+ .debug_line_str 0 : { *(.debug_line_str) } \
> >+ .debug_loclists 0 : { *(.debug_loclists) } \
> >+ .debug_rnglists 0 : { *(.debug_rnglists) } \
> >+ .debug_str_offsets 0 : { *(.debug_str_offsets) }
>
> Consider adding .debug_names for the accelerator table.
> It is the DWARF v5 version of .debug_pub{names,types} (which are mentioned
> a few lines above).

I hadn't seen that section produced in my limited testing. Being a
fan of TDD, I kind of would like to see the linker warn on orphan
section placement, then add it to the list, as I did with the above.
Do you have more info on when or how .debug_pub* can be produced?

Thanks for the rest of the feedback, I'll incorporate it into v2.

--
Thanks,
~Nick Desaulniers

[Arvind Sankar]

On Wed, Oct 21, 2020 at 06:21:06PM -0700, Nick Desaulniers wrote:
> DWARF5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. Further -gdwarf-X where X is an unsupported value doesn't
> produce an error in $(CC). GNU `as` only recently gained support for
> specifying -gdwarf-5.

Do you have more details here? On godbolt.org, gcc does report an error
for unsupported dwarf versions.

https://godbolt.org/z/G35798

gcc does not seem to pass the -gdwarf-* options to the assembler when
compiling C source. For assembler, gcc will pass an appropriate option
depending on the version of binutils it was configured with: if the
assembler doesn't support dwarf-5 it can call it with --gdwarf2 for eg.

If the user is using a properly configured toolchain it doesn't look
like it should be an issue to just use cc-option?

[Nick Desaulniers]

On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <nive...@alum.mit.edu> wrote:
>
> On Wed, Oct 21, 2020 at 06:21:06PM -0700, Nick Desaulniers wrote:
> > Further -gdwarf-X where X is an unsupported value doesn't
> > produce an error in $(CC).
>

> Do you have more details here? On godbolt.org, gcc does report an error
> for unsupported dwarf versions.
>
> https://godbolt.org/z/G35798
>
> gcc does not seem to pass the -gdwarf-* options to the assembler when
> compiling C source. For assembler, gcc will pass an appropriate option
> depending on the version of binutils it was configured with: if the
> assembler doesn't support dwarf-5 it can call it with --gdwarf2 for eg.
>
> If the user is using a properly configured toolchain it doesn't look
> like it should be an issue to just use cc-option?

I wrote the base patch back in May, and didn't revisit until recently.
I could have sworn the cc-option silently failed for the check
cc-option does, which is /dev/null input. I need to recheck that, but
it doesn't hurt to simply include it for now, which I've done in a v2
I'm about to send.
--
Thanks,
~Nick Desaulniers

[Arvind Sankar]

This is giving me deja vu about the -gz=zlib option.

Didn't Masahiro fix the cc-option issue with
4d0831e8a029 ("kconfig: unify cc-option and as-option")

The existing -Wa,-gdwarf-2 in the Makefile seems bogus, btw. GCC 4.9.0
at least appears to pass on --gdwarf2 automatically.

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a fixup already sent, but necessary for trying to use
LLVM_IAS=1 with ToT LLVM.
https://lore.kernel.org/stable/20201103012358....@google.com/

Patches 2 and 3 are cleanups that lay the ground work and aren't DWARF
v5 specific. In particular, I would like to see Patch 2 sent to stable
so that Android and CrOS can move to LLVM_IAS=1 ASAP.

Patch 4 implements Kconfig and Kbuild support for DWARFv5.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

Fangrui Song (1):
x86_64: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S

Nick Desaulniers (3):
Kbuild: do not emit debug info for assembly with LLVM_IAS=1
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 13 +++++++++----
arch/x86/lib/memcpy_64.S | 4 +---
arch/x86/lib/memmove_64.S | 4 +---
arch/x86/lib/memset_64.S | 4 +---
include/asm-generic/vmlinux.lds.h | 6 +++++-
lib/Kconfig.debug | 27 +++++++++++++++++++++++----
scripts/test_dwarf5_support.sh | 9 +++++++++
7 files changed, 49 insertions(+), 18 deletions(-)
create mode 100755 scripts/test_dwarf5_support.sh

--
2.29.1.341.ge80a0c044ae-goog

[Nick Desaulniers]

From: Fangrui Song <mas...@google.com>

Commit 393f203f5fd5 ("x86_64: kasan: add interceptors for
memset/memmove/memcpy functions") added .weak directives to
arch/x86/lib/mem*_64.S instead of changing the existing ENTRY macros to
WEAK. This can lead to the assembly snippet `.weak memcpy ... .globl
memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL
memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since
https://reviews.llvm.org/D90108) will error on such an overridden symbol
binding.

Commit ef1e03152cb0 ("x86/asm: Make some functions local") changed ENTRY in
arch/x86/lib/memcpy_64.S to SYM_FUNC_START_LOCAL, which was ineffective due to
the preceding .weak directive.

Use the appropriate SYM_FUNC_START_WEAK instead.

Fixes: 393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions")
Fixes: ef1e03152cb0 ("x86/asm: Make some functions local")
Reported-by: Sami Tolvanen <samito...@google.com>
Signed-off-by: Fangrui Song <mas...@google.com>
Tested-by: Nathan Chancellor <natecha...@gmail.com>
Cc: <sta...@vger.kernel.org>

---
arch/x86/lib/memcpy_64.S | 4 +---
arch/x86/lib/memmove_64.S | 4 +---
arch/x86/lib/memset_64.S | 4 +---

3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 037faac46b0c..1e299ac73c86 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -16,8 +16,6 @@
* to a jmp to memcpy_erms which does the REP; MOVSB mem copy.
*/

-.weak memcpy
-
/*
* memcpy - Copy a memory block.
*
@@ -30,7 +28,7 @@
* rax original destination
*/
SYM_FUNC_START_ALIAS(__memcpy)
-SYM_FUNC_START_LOCAL(memcpy)
+SYM_FUNC_START_WEAK(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
"jmp memcpy_erms", X86_FEATURE_ERMS

diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 7ff00ea64e4f..41902fe8b859 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -24,9 +24,7 @@
* Output:
* rax: dest
*/
-.weak memmove
-
-SYM_FUNC_START_ALIAS(memmove)
+SYM_FUNC_START_WEAK(memmove)
SYM_FUNC_START(__memmove)

mov %rdi, %rax
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 9ff15ee404a4..0bfd26e4ca9e 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -6,8 +6,6 @@
#include <asm/alternative-asm.h>
#include <asm/export.h>

-.weak memset
-
/*
* ISO C memset - set a memory block to a byte value. This function uses fast
* string to get better performance than the original function. The code is
@@ -19,7 +17,7 @@
*
* rax original destination
*/
-SYM_FUNC_START_ALIAS(memset)
+SYM_FUNC_START_WEAK(memset)
SYM_FUNC_START(__memset)
/*
* Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
--
2.29.1.341.ge80a0c044ae-goog

[Nick Desaulniers]

Clang's integrated assembler produces the warning for assembly files:

warning: DWARF2 only supports one section per compilation unit

If -Wa,-gdwarf-* is unspecified, then debug info is not emitted. This
will be re-enabled for new DWARF versions in a follow up patch.

Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
LLVM=1 LLVM_IAS=1 for x86_64 and arm64.

Cc: <sta...@vger.kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/716
Reported-by: Nathan Chancellor <natecha...@gmail.com>
Suggested-by: Dmitry Golovin <di...@golovin.in>
Suggested-by: Sedat Dilek <sedat...@gmail.com>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index f353886dbf44..75b1a3dcbf30 100644
--- a/Makefile
+++ b/Makefile
@@ -826,7 +826,9 @@ else
DEBUG_CFLAGS += -g
endif

+ifndef LLVM_IAS
KBUILD_AFLAGS += -Wa,-gdwarf-2
+endif

ifdef CONFIG_DEBUG_INFO_DWARF4
DEBUG_CFLAGS += -gdwarf-4
--
2.29.1.341.ge80a0c044ae-goog

[Nick Desaulniers]

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.

Suggested-by: Fangrui Song <mas...@google.com>
Suggested-by: Masahiro Yamada <masa...@kernel.org>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 14 ++++++++------
lib/Kconfig.debug | 19 +++++++++++++++----
2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index 75b1a3dcbf30..e23786a4c1c7 100644
--- a/Makefile
+++ b/Makefile
@@ -826,12 +826,14 @@ else
DEBUG_CFLAGS += -g
endif

-ifndef LLVM_IAS
-KBUILD_AFLAGS += -Wa,-gdwarf-2
-endif
-
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS += -gdwarf-4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
+ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
+# Binutils 2.35+ required for -gdwarf-4+ support.
+dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
+DEBUG_CFLAGS += $(dwarf-aflag)
+KBUILD_AFLAGS += $(dwarf-aflag)
endif

ifdef CONFIG_DEBUG_INFO_REDUCED
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 83a860126897..03c494eefabd 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,14 +256,25 @@ config DEBUG_INFO_SPLIT

to know about the .dwo files and include them.
Incompatible with older versions of ccache.

+choice
+ prompt "DWARF version"

+ help
+ Which version of DWARF debug info to emit.
+
+config DEBUG_INFO_DWARF2

+ bool "Generate DWARF v2 debuginfo"
+ help
+ Generate DWARF v2 debug info.

+
config DEBUG_INFO_DWARF4
bool "Generate dwarf4 debuginfo"
depends on $(cc-option,-gdwarf-4)
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.

+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.

+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+

+endchoice # "DWARF version"

config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"

--
2.29.1.341.ge80a0c044ae-goog

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive

support. GNU `as` only recently gained support for specifying

-gdwarf-5.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head -n 5 | grep version
or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Suggested-by: Masahiro Yamada <masa...@kernel.org>
Suggested-by: Jakub Jelinek <ja...@redhat.com>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 1 +
include/asm-generic/vmlinux.lds.h | 6 +++++-
lib/Kconfig.debug | 8 ++++++++
scripts/test_dwarf5_support.sh | 9 +++++++++
4 files changed, 23 insertions(+), 1 deletion(-)

create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile

index e23786a4c1c7..9056bac0ff85 100644
--- a/Makefile
+++ b/Makefile
@@ -828,6 +828,7 @@ endif

dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
ifneq ($(dwarf-version-y)$(LLVM_IAS),21)

# Binutils 2.35+ required for -gdwarf-4+ support.

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index b2b3d81b1535..76ce62c77029 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -829,7 +829,11 @@

.debug_types 0 : { *(.debug_types) } \
/* DWARF 5 */ \
.debug_macro 0 : { *(.debug_macro) } \
- .debug_addr 0 : { *(.debug_addr) }
+ .debug_addr 0 : { *(.debug_addr) } \
+ .debug_line_str 0 : { *(.debug_line_str) } \
+ .debug_loclists 0 : { *(.debug_loclists) } \
+ .debug_rnglists 0 : { *(.debug_rnglists) } \
+ .debug_str_offsets 0 : { *(.debug_str_offsets) }

/* Stabs debugging sections. */
#define STABS_DEBUG \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug

index 03c494eefabd..c5b54ba51060 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -274,6 +274,14 @@ config DEBUG_INFO_DWARF4

It makes the debug information larger, but it significantly

improves the success of resolving variables in gdb on optimized code.

+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF5 debuginfo"
+ depends on $(cc-option,-gdwarf-5)

+ depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
+ help
+ Genereate dwarf5 debug info. Requires binutils 2.35+, gcc 5.1+, and
+ gdb 8.0+.
+

endchoice # "DWARF version"

config DEBUG_INFO_BTF

diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
new file mode 100755

index 000000000000..156ad5ec4274
--- /dev/null
+++ b/scripts/test_dwarf5_support.sh
@@ -0,0 +1,9 @@

+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+

+# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
+# in binutils < 2.35.
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
+set -e
+echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
--
2.29.1.341.ge80a0c044ae-goog

[Jakub Jelinek]

On Tue, Nov 03, 2020 at 02:21:22PM -0800, Nick Desaulniers wrote:
> > > This script fails for GCC 10.
> >
> > One thing is GCC DWARF-5 support, that is whether the compiler
> > will support -gdwarf-5 flag, and that support should be there from
> > GCC 7 onwards.
>
> I should improve my Kconfig check; I don't actually have a test for
> -gdwarf-5 for the compiler. In godbolt, it looks like -gdwarf-5
> produces an error from GCC up until GCC 5.1. Does (5.1 < GCC < 7) not
> produce DWARF5?

No. After all, those versions also predate DWARF5.
All 5.1 - 6.x did was start accepting -gdwarf-5 as experimental option
that enabled some small DWARF subset (initially only a few DW_LANG_* codes
newly added to DWARF5 drafts). Only GCC 7 (released after DWARF 5 has
been finalized) started emitting DWARF5 section headers and got most of the
DWARF5 changes in, e.g. including switching over most of the now
standardized GNU extensions from their DW_*_GNU_* codes to DWARF5 DW_*).
With GCC 5/6, you get:
echo 'int i;' | gcc -c -o /tmp/test.o -xc - -gdwarf-5; readelf -wi /tmp/test.o | grep Version:
Version: 4
while with 7+
Version: 5
instead.

> Maybe there's a more specific test you had in mind?

Guess what you want to test is what version you actually get in .debug_info
if you compile with -gdwarf-5.

> > Another separate thing is whether the assembler does support
> > the -gdwarf-5 option (i.e. if you can compile assembler files
> > with -Wa,-gdwarf-5) for GNU as I think that is binutils 35.1,
> > i.e. very new); but only if you want to pass the -Wa,-gdwarf-5
> > only when compiling *.s and *.S files. That option is about whether
> > the assembler will emit DWARF5 or DWARF2 .debug_line.
> > It is fine to compile C sources with -gdwarf-5 and use DWARF2
> > .debug_line for assembler files if as doesn't support it.
> >
> > Yet another thing is if you can pass -Wa,-gdwarf-5 even when
> > compiling C files. There are several bugs in that category that have been
> > fixed only in the last few days on binutils trunk, I'd suggest
> > just not to bother, GCC 11 will have proper test for fixed assembler
> > and will pass -gdwarf-5 to as when compiling even C sources with -gdwarf-5.
>
> Do you have links? I would prefer to do feature detection rather than

The
https://gcc.gnu.org/r11-3693
https://gcc.gnu.org/r11-4338
commits contain those tests in gcc/configure.ac

Jakub

[kernel test robot]

Hi Nick,

I love your patch! Yet something to improve:

[auto build test ERROR on kbuild/for-next]
[also build test ERROR on asm-generic/master linus/master v5.10-rc2 next-20201104]
[cannot apply to tip/x86/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url: https://github.com/0day-ci/linux/commits/Nick-Desaulniers/Kbuild-DWARF-v5-support/20201104-085610
base: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
config: ia64-randconfig-r034-20201104 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/f8b8c21feb85f4422b79a96e0b56cf4e8ff53274
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nick-Desaulniers/Kbuild-DWARF-v5-support/20201104-085610
git checkout f8b8c21feb85f4422b79a96e0b56cf4e8ff53274
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=ia64

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <l...@intel.com>

All errors (new ones prefixed by >>):

{standard input}: Assembler messages:
>> {standard input}:34: Error: file number 1 already allocated

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuil...@lists.01.org

[Nathan Chancellor]

On Tue, Nov 03, 2020 at 04:53:41PM -0800, Nick Desaulniers wrote:
> Clang's integrated assembler produces the warning for assembly files:
>
> warning: DWARF2 only supports one section per compilation unit
>
> If -Wa,-gdwarf-* is unspecified, then debug info is not emitted. This

Is this something that should be called out somewhere? If I understand
this correctly, LLVM_IAS=1 + CONFIG_DEBUG_INFO=y won't work? Maybe this
should be handled in Kconfig?

> will be re-enabled for new DWARF versions in a follow up patch.
>
> Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
> LLVM=1 LLVM_IAS=1 for x86_64 and arm64.
>
> Cc: <sta...@vger.kernel.org>
> Link: https://github.com/ClangBuiltLinux/linux/issues/716
> Reported-by: Nathan Chancellor <natecha...@gmail.com>
> Suggested-by: Dmitry Golovin <di...@golovin.in>

If you happen to respin, Dmitry deserves a Reported-by tag too :)

> Suggested-by: Sedat Dilek <sedat...@gmail.com>
> Signed-off-by: Nick Desaulniers <ndesau...@google.com>

Regardless of the other two comments, this is fine as is as a fix for
stable to unblock Android + CrOS since we have been running something
similar to it in CI:

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

> ---
> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index f353886dbf44..75b1a3dcbf30 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,7 +826,9 @@ else
> DEBUG_CFLAGS += -g
> endif
>
> +ifndef LLVM_IAS

Nit: this should probably match the existing LLVM_IAS check

ifneq ($(LLVM_IAS),1)

[Fangrui Song]

The root cause is that DWARF v2 has no DW_AT_ranges, so it cannot
represent non-contiguous address ranges. It seems that GNU as -gdwarf-3
emits DW_AT_ranges as well and emits an entry for a non-executable section.
In any case, the option is of very low value, at least for LLVM.


Reviewed-by: Fangrui Song <mas...@google.com>

[Nick Desaulniers]

On Wed, Nov 4, 2020 at 10:58 PM Nathan Chancellor
<natecha...@gmail.com> wrote:
>
> On Tue, Nov 03, 2020 at 04:53:41PM -0800, Nick Desaulniers wrote:
> > Clang's integrated assembler produces the warning for assembly files:
> >
> > warning: DWARF2 only supports one section per compilation unit
> >
> > If -Wa,-gdwarf-* is unspecified, then debug info is not emitted. This
>
> Is this something that should be called out somewhere? If I understand
> this correctly, LLVM_IAS=1 + CONFIG_DEBUG_INFO=y won't work? Maybe this
> should be handled in Kconfig?

Specifically, debug info will not be emitted, for assembler source
files. It will still be emitted for C source files (via -gdwarf-*).
-Wa,-gdwarf-* only affects assembler file sources.

>
> > will be re-enabled for new DWARF versions in a follow up patch.
> >
> > Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
> > LLVM=1 LLVM_IAS=1 for x86_64 and arm64.
> >
> > Cc: <sta...@vger.kernel.org>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/716
> > Reported-by: Nathan Chancellor <natecha...@gmail.com>
> > Suggested-by: Dmitry Golovin <di...@golovin.in>
>
> If you happen to respin, Dmitry deserves a Reported-by tag too :)

Sure.

>
> > Suggested-by: Sedat Dilek <sedat...@gmail.com>
> > Signed-off-by: Nick Desaulniers <ndesau...@google.com>
>
> Regardless of the other two comments, this is fine as is as a fix for
> stable to unblock Android + CrOS since we have been running something
> similar to it in CI:
>
> Reviewed-by: Nathan Chancellor <natecha...@gmail.com>
>
> > ---
> > Makefile | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index f353886dbf44..75b1a3dcbf30 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -826,7 +826,9 @@ else
> > DEBUG_CFLAGS += -g
> > endif
> >
> > +ifndef LLVM_IAS
>
> Nit: this should probably match the existing LLVM_IAS check

Sure, will send a v3. Going to just send this for now, as it's
blocking some downstream work I'm trying to get done in Android.

>
> ifneq ($(LLVM_IAS),1)
>
> > KBUILD_AFLAGS += -Wa,-gdwarf-2
> > +endif
> >
> > ifdef CONFIG_DEBUG_INFO_DWARF4
> > DEBUG_CFLAGS += -gdwarf-4
> > --
> > 2.29.1.341.ge80a0c044ae-goog
> >

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

Clang's integrated assembler produces the warning for assembly files:

warning: DWARF2 only supports one section per compilation unit

If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for
assembly sources (it is still emitted for C sources). This will be
re-enabled for newer DWARF versions in a follow up patch.

Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
LLVM=1 LLVM_IAS=1 for x86_64 and arm64.

Cc: <sta...@vger.kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/716

Reported-by: Dmitry Golovin <di...@golovin.in>

Reported-by: Nathan Chancellor <natecha...@gmail.com>
Suggested-by: Dmitry Golovin <di...@golovin.in>

Suggested-by: Nathan Chancellor <natecha...@gmail.com>
Suggested-by: Sedat Dilek <sedat...@gmail.com>
Reviewed-by: Fangrui Song <mas...@google.com>
Reviewed-by: Nathan Chancellor <natecha...@gmail.com>
Signed-off-by: Nick Desaulniers <ndesau...@google.com>

---
Makefile | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile

index f353886dbf44..7e899d356902 100644

--- a/Makefile
+++ b/Makefile
@@ -826,7 +826,9 @@ else
DEBUG_CFLAGS += -g
endif

+ifneq ($(LLVM_IAS),1)

KBUILD_AFLAGS += -Wa,-gdwarf-2
+endif

ifdef CONFIG_DEBUG_INFO_DWARF4
DEBUG_CFLAGS += -gdwarf-4
--

2.29.2.222.g5d2a92d10f8-goog

[Jian Cai]

Thanks for the patch! Compile-tested on mainline (with defconfig) and ChromeOS kernel 5.4 (with olddefconfig) and both worked. 

--
You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201109183528.1391885-1-ndesaulniers%40google.com.

[Jian Cai]

Tested-by: Jian Cai <jia...@google.com> # Compile-tested on mainline (with defconfig) and ChromeOS (with olddefconfig).

[Nick Desaulniers]

Hi Masahiro, have you had time to review v3 of this patch?

On Mon, Nov 9, 2020 at 10:35 AM Nick Desaulniers

--
Thanks,
~Nick Desaulniers

[Jian Cai]

I also verified that with this patch Chrome OS devices booted with either GNU assembler or LLVM's integrated assembler. With this patch, IAS no longer produces extra warnings compared to GNU as on Chrome OS and would remove the last blocker of enabling IAS on it.

Tested-by: Jian Cai <jia...@google.com> # Compile-tested on mainline (with defconfig) and boot-tested on ChromeOS (with olddefconfig).

--
You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdnxAr7UdjUiuttj%3Dbz1_voK1qUvpOvSY35qOZ60%2BE8LBA%40mail.gmail.com.

[Nick Desaulniers]

Hi Masahiro,
I would appreciate any feedback you have on this patch.

--
Thanks,
~Nick Desaulniers

[Arvind Sankar]

For LLVM_IAS=1, adding dwarf-aflag to DEBUG_CFLAGS should not be
necessary, no? This seems to add it for dwarf-4.

The as-option check will only work on binutils 2.35.1 onwards: earlier
versions will silently accept any -gdwarf-N option. Do we care? I think
it'll just get dwarf-2 for assembly files even though dwarf-4 might have
been configured. The earlier versions only error if the double-hyphen
form --gdwarf-N is used.

More generally, do we want to force this option via -Wa or should we
leave it up to the compiler driver when we can? For both Clang/IAS and
gcc/binutils, passing -gdwarf-N in KBUILD_AFLAGS will allow the compiler
to pass on the appropriate option to the assembler (with gcc you only
get --gdwarf-2 for the assembler except on trunk though). The only case
that would absolutely require -Wa is Clang without IAS, might be worth
adding the ability to pass on the flag to the external assembler?

Btw, is -gsplit-dwarf at all useful for assembler files?

[Segher Boessenkool]

On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote:
> Btw, is -gsplit-dwarf at all useful for assembler files?

If you invoke the assembler via the compiler, with that flag it still
creates separate .o and .dwo files (via objcopy invocations as usual).
Whether that is useful depends on if you have any debug info that can
be split :-)


Segher

[Arvind Sankar]

Right, the latter was what I was really asking :) We don't currently
pass -gsplit-dwarf for assembler and I was wondering if that mattered.

Thanks.

[Arvind Sankar]

On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. GNU `as` only recently gained support for specifying
> -gdwarf-5.

With gcc, using -gdwarf-5 even without -Wa,--gdwarf-5 results in
considerably smaller debug info. gcc does not seem to generate the .file 0
directive that causes older GNU as to barf.

Should the assembler support check be restricted to CC_IS_CLANG?

> /* Stabs debugging sections. */
> #define STABS_DEBUG \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 03c494eefabd..c5b54ba51060 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -274,6 +274,14 @@ config DEBUG_INFO_DWARF4
> It makes the debug information larger, but it significantly
> improves the success of resolving variables in gdb on optimized code.
>
> +config DEBUG_INFO_DWARF5
> + bool "Generate DWARF5 debuginfo"
> + depends on $(cc-option,-gdwarf-5)
> + depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
> + help
> + Genereate dwarf5 debug info. Requires binutils 2.35+, gcc 5.1+, and
> + gdb 8.0+.
> +
> endchoice # "DWARF version"

Perhaps this can be expanded with some description of the advantages of
dwarf5 over dwarf4?

>
> config DEBUG_INFO_BTF
> diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> new file mode 100755
> index 000000000000..156ad5ec4274
> --- /dev/null
> +++ b/scripts/test_dwarf5_support.sh
> @@ -0,0 +1,9 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
> +# in binutils < 2.35.
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
> +set -e
> +echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -

This also actually needs --gdwarf-5 to really check the support for the
option, but older versions should error on the .file 0 in any case.

[Segher Boessenkool]

On Tue, Nov 24, 2020 at 11:56:02AM -0500, Arvind Sankar wrote:
> On Mon, Nov 23, 2020 at 06:33:57PM -0600, Segher Boessenkool wrote:
> > On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote:
> > > Btw, is -gsplit-dwarf at all useful for assembler files?
> >
> > If you invoke the assembler via the compiler, with that flag it still
> > creates separate .o and .dwo files (via objcopy invocations as usual).
> > Whether that is useful depends on if you have any debug info that can
> > be split :-)
>

> Right, the latter was what I was really asking :) We don't currently
> pass -gsplit-dwarf for assembler and I was wondering if that mattered.

If there is any debug info in the .s files, it will all end up in the .o
file, not a .dwo file. That may matter aesthetically, and it can cost a
few bytes of disk space, but it doesn't matter functionally (GDB will
search in both places).


Segher

[Masahiro Yamada]

On Tue, Nov 24, 2020 at 3:42 AM Nick Desaulniers
<ndesau...@google.com> wrote:
>
> Hi Masahiro,
> I would appreciate any feedback you have on this patch.
>

Applied to linux-kbuild. Thanks.

--
Best Regards
Masahiro Yamada

[Masahiro Yamada]

This changes the behavior.

For the Dwarf-2 case,

Previously, -gdwarf-2 was passed to $(CC),
so the debug info was generated by gcc.

Now, -Wa,-gdwarf-2 is passed to $(CC).
-gdwarf-2 is handled by GNU as.
So, the source info points to /tmp/<hash>.s
instead of the original .c file.



Handling the Dwarf capability is very complicated.

Are you still working for v3?

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201104005343.4192504-4-ndesaulniers%40google.com.

[Fāng-ruì Sòng]

We can bump -Wa,-gdwarf-2 to -Wa,-gdwarf-3 since GNU actually emits
DWARF v3 DW_AT_ranges (see
https://sourceware.org/bugzilla/show_bug.cgi?id=26850 )
This can avoid the `warning: DWARF2 only supports one section per
compilation unit` warning for Clang.

Deleting -Wa,-gdwarf-2 also sounds good to me if people can verify
their debugging experience is not regressed (I believe it is useless).


--
宋方睿

[Nick Desaulniers]

On Mon, Nov 30, 2020 at 10:05 AM Masahiro Yamada <masa...@kernel.org> wrote:
>

Yes, I plan to revisit the series based on all of the feedback thus
far. Lately I'm focused on enabling LLVM_IAS=1 for Android; but I
would like to see this land so that the Linux kernel may provide
coverage and feedback to the toolchain developers for DWARF v5 (as
well as reduced binary image sizes). Maybe later this week I'll have
time to revisit.
--
Thanks,
~Nick Desaulniers

[Masahiro Yamada]

The choice menu looks like follows:

(X) Generate DWARF v2 debuginfo
( ) Generate dwarf4 debuginfo
( ) Generate DWARF5 debuginfo


Upper / Lower case inconsistency.

[Masahiro Yamada]

On Tue, Dec 1, 2020 at 5:27 AM 'Fāng-ruì Sòng' via Clang Built Linux

I am not a DWARF spec expert.

Please teach me.

In my understanding, "DWARF2 only supports one section ..."
is warned only when building .S files with LLVM_IAS=1

If this is due to the limitation of DWARF v2, why is it OK to
build .c files with LLVM_IAS?

>
> Deleting -Wa,-gdwarf-2 also sounds good to me if people can verify
> their debugging experience is not regressed (I believe it is useless).
>
>
> --
> 宋方睿
>

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAFP8O3Ki9HoqcV450fn29fBOWAbmuGAdB6USLz8pGsW4Vzf7sg%40mail.gmail.com.

[Masahiro Yamada]

On Tue, Dec 1, 2020 at 5:45 AM 'Nick Desaulniers' via Clang Built

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdmPeOEA4dfODCKLE4A_M-SF5RBVFEf-NuiTkUTXAbh-5w%40mail.gmail.com.


In my understanding, the complexity comes from the fact
we are mixing up the $(CC) capability and $(AS) capability.

They are orthogonal if I understand correctly.


When building *.c files, the .debug* sections are generated by
gcc (or clang), and embedded into the intermediate *.s files.
The assembler (GAS or clang's IAS) simply transforms it
into byte stream in *.o. So we do not care about the assembler capability.


When building *.S files, the .debug* sections are generated by
the assembler. Here, the assembler capability is important.
Unless we use binutils 2.35+ or clang IAS,
DWARF v2 is the only possible choice.



So, we need two separate choices to handle this properly, I think.

The following is the rough sketch.





# The value is 2, 3, 4, or 5 depending on the assembler in use.
# Unfortunately, we cannot check this by $(cc-option, -Wa,-gdwarf-4)
# because GAS <= 2.34 accepts any -gdwarf-<N>.
# readelf --debug-dump=info and grep or something?
config AS_SUPPORTS_DWARF_VERSION
int $(shell scripts/as_dwarf_support.sh)



choice
"DWARF version for C code debugging"

config CC_DEBUG_INFO_DWARF2
bool "..."

config CC_DEBUG_INFO_DWARF4
bool "..."

config CC_DEBUG_INFO_DWARF5
bool "..."
depends on GCC_VERSION >= 700000 || CC_IS_CLANG
depends on AS_SUPPORTS_DWARF_VERSION >= 5
help
gcc7+ or clang supports this.
Unfortunately, we also need to check assembler capability
because GAS <= 2.34 do not understand ".file 0"

endchoice



choice
"DWARF version for assembly code debugging"

config AS_DEBUG_INFO_DWARF2
bool "..."

config AS_DEBUG_INFO_DWARF4
bool "..."
depends on AS_SUPPORTS_DWARF_VERSION >= 4

config AS_DEBUG_INFO_DWARF5
bool "..."
depends on AS_SUPPORTS_DWARF_VERSION >= 5

endchoice

[Segher Boessenkool]

On Tue, Dec 01, 2020 at 12:38:16PM +0900, Masahiro Yamada wrote:
> > We can bump -Wa,-gdwarf-2 to -Wa,-gdwarf-3 since GNU actually emits
> > DWARF v3 DW_AT_ranges (see
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26850 )
> > This can avoid the `warning: DWARF2 only supports one section per
> > compilation unit` warning for Clang.

That warning should be "there can be only one section with executable
code per translation unit", or similar.

> I am not a DWARF spec expert.

Neither am I.

> Please teach me.
>
> In my understanding, "DWARF2 only supports one section ..."
> is warned only when building .S files with LLVM_IAS=1

.S files are simply run through the C preprocessor first, and then given
to the assembler. The only difference there should be wrt debug info is
you could have some macros that expand to assembler debug statements.

> If this is due to the limitation of DWARF v2, why is it OK to
> build .c files with LLVM_IAS?

The compiler can of course make sure not to use certain constructs in
its generated assembler code, while the assembler will have to swallow
whatever the user wrote.


Segher

[Fāng-ruì Sòng]

These are all correct. You can use `llvm-dwarfdump a.o` to dump a .o file.
It has one DW_TAG_compile_unit. If the translation unit has a single
contiguous address range, the assembler can emit a pair of
DW_AT_low_pc/DW_AT_high_pc (available in DWARF v2). In the case of
multiple executable sections, it is not guaranteed that in the final
linked image the sections will be contiguous, so the assembler has to
assume there may be non-contiguous address ranges and use DW_AT_ranges.

Unfortunately DW_AT_ranges was introduced in DWARF v3 and technically
not available in DWARF v2. But GNU as ignores this and emits
DW_AT_ranges anyway (this is probably fine - like using a GNU extension).

If -Wa,-gdwarf-2 -> -Wa,-gdwarf-3 can eliminate the LLVM integrated
assembler's warning, we should do it. If people think -Wa,-gdwarf-2 is
not useful and want to delete it, I'll be happier. Whether it is
necessary to use -Wa,-gdwarf-2/-Wa,-gdwarf-5? Personally I would think
this is unnecessary, but I won't mind if people don't mind the
additional complexity in Makefile. (I implemented the -gdwarf-5 address
range stuff for the integrated assembler).

[Nick Desaulniers]

On Tue, Nov 3, 2020 at 4:17 PM Arvind Sankar <nive...@alum.mit.edu> wrote:
>
> On Tue, Nov 03, 2020 at 04:05:36PM -0800, Nick Desaulniers wrote:
> > On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <nive...@alum.mit.edu> wrote:
> > >
> > > On Wed, Oct 21, 2020 at 06:21:06PM -0700, Nick Desaulniers wrote:
> > > > Further -gdwarf-X where X is an unsupported value doesn't
> > > > produce an error in $(CC).
> > >
> > > Do you have more details here? On godbolt.org, gcc does report an error
> > > for unsupported dwarf versions.
> > >
> > > https://godbolt.org/z/G35798
> > >
> > > gcc does not seem to pass the -gdwarf-* options to the assembler when
> > > compiling C source. For assembler, gcc will pass an appropriate option
> > > depending on the version of binutils it was configured with: if the
> > > assembler doesn't support dwarf-5 it can call it with --gdwarf2 for eg.
> > >
> > > If the user is using a properly configured toolchain it doesn't look
> > > like it should be an issue to just use cc-option?
> >
> > I wrote the base patch back in May, and didn't revisit until recently.
> > I could have sworn the cc-option silently failed for the check
> > cc-option does, which is /dev/null input. I need to recheck that, but
> > it doesn't hurt to simply include it for now, which I've done in a v2
> > I'm about to send.
> > --
> > Thanks,
> > ~Nick Desaulniers
>
> This is giving me deja vu about the -gz=zlib option.
>
> Didn't Masahiro fix the cc-option issue with
> 4d0831e8a029 ("kconfig: unify cc-option and as-option")
>
> The existing -Wa,-gdwarf-2 in the Makefile seems bogus, btw. GCC 4.9.0
> at least appears to pass on --gdwarf2 automatically.

It looks like we don't need -Wa,-gdwarf-2 when -gdwarf-2 is set. So I
can probably drop
+DEBUG_CFLAGS += $(dwarf-aflag)
from v2. Will retest though.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <nive...@alum.mit.edu> wrote:
>
> On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> > DWARF v5 is the latest standard of the DWARF debug info format.
> >
> > Feature detection of DWARF5 is onerous, especially given that we've
> > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > support. GNU `as` only recently gained support for specifying
> > -gdwarf-5.
>
> With gcc, using -gdwarf-5 even without -Wa,--gdwarf-5 results in
> considerably smaller debug info. gcc does not seem to generate the .file 0
> directive that causes older GNU as to barf.
>
> Should the assembler support check be restricted to CC_IS_CLANG?

No, because if LLVM_IAS=1 then the assembler support need not be checked.

>
> > /* Stabs debugging sections. */
> > #define STABS_DEBUG \
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 03c494eefabd..c5b54ba51060 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -274,6 +274,14 @@ config DEBUG_INFO_DWARF4
> > It makes the debug information larger, but it significantly
> > improves the success of resolving variables in gdb on optimized code.
> >
> > +config DEBUG_INFO_DWARF5
> > + bool "Generate DWARF5 debuginfo"
> > + depends on $(cc-option,-gdwarf-5)
> > + depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
> > + help
> > + Genereate dwarf5 debug info. Requires binutils 2.35+, gcc 5.1+, and
> > + gdb 8.0+.
> > +
> > endchoice # "DWARF version"
>
> Perhaps this can be expanded with some description of the advantages of
> dwarf5 over dwarf4?

Will do.

>
> >
> > config DEBUG_INFO_BTF
> > diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> > new file mode 100755
> > index 000000000000..156ad5ec4274
> > --- /dev/null
> > +++ b/scripts/test_dwarf5_support.sh
> > @@ -0,0 +1,9 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
> > +# in binutils < 2.35.
> > +# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> > +# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
> > +set -e
> > +echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
>
> This also actually needs --gdwarf-5 to really check the support for the
> option, but older versions should error on the .file 0 in any case.

Based on Jakub's feedback on the earlier thread
https://lore.kernel.org/lkml/20201104121934.GT3788@tucnak/
it sounds like the dwarf version also needs to be dumped since GCC 5 <
x < 7 accepts --gdwarf-5, but did not produce DWARF Version 5 debug
info.

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <ndesau...@google.com> wrote:
>
> On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <nive...@alum.mit.edu> wrote:
> >
> > On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> > > DWARF v5 is the latest standard of the DWARF debug info format.
> > >
> > > Feature detection of DWARF5 is onerous, especially given that we've
> > > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > > support. GNU `as` only recently gained support for specifying
> > > -gdwarf-5.
> >
> > With gcc, using -gdwarf-5 even without -Wa,--gdwarf-5 results in
> > considerably smaller debug info. gcc does not seem to generate the .file 0
> > directive that causes older GNU as to barf.
> >
> > Should the assembler support check be restricted to CC_IS_CLANG?
>
> No, because if LLVM_IAS=1 then the assembler support need not be checked.

Also, if your version of GCC supports DWARF Version 5, but your
version of GAS does not, then I'm more inclined to not allow
CONFIG_DEBUG_INFO_DWARF5 to be selectable, rather than mix and match
or partially support this for one but not the other. Either all tools
used support DWARF 5, or you don't get to use DWARF 5.

> > > config DEBUG_INFO_BTF
> > > diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> > > new file mode 100755
> > > index 000000000000..156ad5ec4274
> > > --- /dev/null
> > > +++ b/scripts/test_dwarf5_support.sh
> > > @@ -0,0 +1,9 @@
> > > +#!/bin/sh
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
> > > +# in binutils < 2.35.
> > > +# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> > > +# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
> > > +set -e
> > > +echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
> >
> > This also actually needs --gdwarf-5 to really check the support for the
> > option, but older versions should error on the .file 0 in any case.
>
> Based on Jakub's feedback on the earlier thread
> https://lore.kernel.org/lkml/20201104121934.GT3788@tucnak/
> it sounds like the dwarf version also needs to be dumped since GCC 5 <
> x < 7 accepts --gdwarf-5, but did not produce DWARF Version 5 debug
> info.

Sigh...llvm-readelf doesn't accept --debug-dump=info for checking the
DWARF version; llvm-dwarfdump works with no args...at this point I'm
tempted to just version check GCC.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

That's needed for non LLVM_IAS=1 builds so that clang informs GAS to
assembler using DWARF Version 5; otherwise every translation unit
fails to assemble with an error from GAS.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.

Suggested-by: Fangrui Song <mas...@google.com>
Suggested-by: Masahiro Yamada <masa...@kernel.org>
Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---
Makefile | 14 ++++++++------

lib/Kconfig.debug | 21 ++++++++++++++++-----
2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index a2ded5029084..2430e1ee7c44 100644

--- a/Makefile
+++ b/Makefile
@@ -826,12 +826,14 @@ else
DEBUG_CFLAGS += -g
endif

-ifneq ($(LLVM_IAS),1)

-KBUILD_AFLAGS += -Wa,-gdwarf-2
-endif
-
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS += -gdwarf-4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
+ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
+# Binutils 2.35+ required for -gdwarf-4+ support.
+dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
+DEBUG_CFLAGS += $(dwarf-aflag)

+KBUILD_AFLAGS += $(dwarf-aflag)
endif

ifdef CONFIG_DEBUG_INFO_REDUCED

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0c7380e36370..04719294a7a3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug

@@ -256,14 +256,25 @@ config DEBUG_INFO_SPLIT
to know about the .dwo files and include them.
Incompatible with older versions of ccache.

+choice
+ prompt "DWARF version"
+ help
+ Which version of DWARF debug info to emit.
+
+config DEBUG_INFO_DWARF2

+ bool "Generate DWARF Version 2 debuginfo"

+ help
+ Generate DWARF v2 debug info.
+
config DEBUG_INFO_DWARF4

- bool "Generate dwarf4 debuginfo"
+ bool "Generate DWARF Version 4 debuginfo"

depends on $(cc-option,-gdwarf-4)
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+
+endchoice # "DWARF version"

config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
--

2.29.2.576.ga3fc446d84-goog

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support. GNU `as` only recently gained support for specifying
-gdwarf-5.

The DWARF version of a binary can be validated with:

$ llvm-dwarfdump vmlinux | head -n 4 | grep version

or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2

515M vmlinux.gcc10.2.dwarf5.compressed
599M vmlinux.gcc10.2.dwarf4.compressed
624M vmlinux.gcc10.2.dwarf2.compressed
630M vmlinux.gcc10.2.dwarf5
765M vmlinux.gcc10.2.dwarf4
809M vmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
option that enabled some small DWARF subset (initially only a few
DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
after DWARF 5 has been finalized) started emitting DWARF5 section
headers and got most of the DWARF5 changes in...

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Suggested-by: Arvind Sankar <nive...@alum.mit.edu>
Suggested-by: Jakub Jelinek <ja...@redhat.com>
Suggested-by: Masahiro Yamada <masa...@kernel.org>
Suggested-by: Fangrui Song <mas...@google.com>
Suggested-by: Caroline Tice <cmt...@google.com>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 1 +
include/asm-generic/vmlinux.lds.h | 6 +++++-

lib/Kconfig.debug | 14 ++++++++++++++
scripts/test_dwarf5_support.sh | 9 +++++++++
4 files changed, 29 insertions(+), 1 deletion(-)
create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index 2430e1ee7c44..45231f6c1935 100644
--- a/Makefile
+++ b/Makefile

@@ -828,6 +828,7 @@ endif

dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
ifneq ($(dwarf-version-y)$(LLVM_IAS),21)

# Binutils 2.35+ required for -gdwarf-4+ support.

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index b2b3d81b1535..76ce62c77029 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -829,7 +829,11 @@
.debug_types 0 : { *(.debug_types) } \
/* DWARF 5 */ \
.debug_macro 0 : { *(.debug_macro) } \
- .debug_addr 0 : { *(.debug_addr) }
+ .debug_addr 0 : { *(.debug_addr) } \
+ .debug_line_str 0 : { *(.debug_line_str) } \
+ .debug_loclists 0 : { *(.debug_loclists) } \
+ .debug_rnglists 0 : { *(.debug_rnglists) } \
+ .debug_str_offsets 0 : { *(.debug_str_offsets) }

/* Stabs debugging sections. */
#define STABS_DEBUG \

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 04719294a7a3..987815771ad6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -274,6 +274,20 @@ config DEBUG_INFO_DWARF4

It makes the debug information larger, but it significantly

improves the success of resolving variables in gdb on optimized code.

+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF Version 5 debuginfo"
+ depends on GCC_VERSION >= 70000 || CC_IS_CLANG

+ depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))

+ help
+ Generate DWARF v5 debug info. Requires binutils 2.35, gcc 7.0+, and
+ gdb 8.0+. Changes to the structure of debug info in Version 5 allow
+ for around 15-18% savings in resulting image and debug info section sizes
+ as compared to DWARF Version 4. DWARF Version 5 standardizes previous
+ extensions such as accelerators for symbol indexing and the format for
+ fission (.dwo/.dwp) files. Users may not want to select this config if
+ they rely on tooling that has not yet been updated to support
+ DWARF Version 5.
+

endchoice # "DWARF version"

config DEBUG_INFO_BTF

diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
new file mode 100755
index 000000000000..156ad5ec4274
--- /dev/null
+++ b/scripts/test_dwarf5_support.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
+# in binutils < 2.35.
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
+set -e
+echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -

--
2.29.2.576.ga3fc446d84-goog

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a cleanup that lays the ground work and isn't DWARF
v5 specific.
Patch 2 implements Kconfig and Kbuild support for DWARFv5.

Changes from v2:
* Drop two of the earlier patches that have been accepted already.
* Add measurements with GCC 10.2 to commit message.
* Update help text as per Arvind with help from Caroline.
* Improve case/wording between DWARF Versions as per Masahiro.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

Nick Desaulniers (2):
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 15 +++++++------
include/asm-generic/vmlinux.lds.h | 6 +++++-
lib/Kconfig.debug | 35 ++++++++++++++++++++++++++-----
scripts/test_dwarf5_support.sh | 9 ++++++++
4 files changed, 53 insertions(+), 12 deletions(-)
create mode 100755 scripts/test_dwarf5_support.sh

--
2.29.2.576.ga3fc446d84-goog

[Nick Desaulniers]

sigh...I ran a broken script to send the series which doesn't cc folks properly.
+ lkml, linux-kbuild
(Might just resend, properly)

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

(minus Chengbin due to bounces)

On Thu, Dec 3, 2020 at 5:11 PM Nick Desaulniers <ndesau...@google.com> wrote:
>

^ I kept the previous help text, but while this may have been the case
when DWARF v4 support was first introduced in GCC, by my (lone)
measure of x86_64 defconfig with gcc 10.2, this doesn't or no longer
seems to be the case. See patch 2 for measurements:
https://lore.kernel.org/lkml/20201204011129.249...@google.com/.
(also, missed the cover letter, here it is:
https://lore.kernel.org/lkml/CAKwvOdkZEiHK01OD420USb0j=F0LcrnRbauv9...@mail.gmail.com/)

> +
> +endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> bool "Generate BTF typeinfo"
> --
> 2.29.2.576.ga3fc446d84-goog
>

--
Thanks,
~Nick Desaulniers

[Arvind Sankar]

On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <ndesau...@google.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <nive...@alum.mit.edu> wrote:
> > >
> > > On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> > > > DWARF v5 is the latest standard of the DWARF debug info format.
> > > >
> > > > Feature detection of DWARF5 is onerous, especially given that we've
> > > > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > > > support. GNU `as` only recently gained support for specifying
> > > > -gdwarf-5.
> > >
> > > With gcc, using -gdwarf-5 even without -Wa,--gdwarf-5 results in
> > > considerably smaller debug info. gcc does not seem to generate the .file 0
> > > directive that causes older GNU as to barf.
> > >
> > > Should the assembler support check be restricted to CC_IS_CLANG?
> >
> > No, because if LLVM_IAS=1 then the assembler support need not be checked.
>
> Also, if your version of GCC supports DWARF Version 5, but your
> version of GAS does not, then I'm more inclined to not allow
> CONFIG_DEBUG_INFO_DWARF5 to be selectable, rather than mix and match
> or partially support this for one but not the other. Either all tools
> used support DWARF 5, or you don't get to use DWARF 5.
>

Why? Does this actually cause any problems?

It seems like the options for gcc can actually be very straightforward:
you just need a cc-option check, and then add -gdwarf-N to both CFLAGS
and AFLAGS and you're done. Adding the -Wa flag is superfluous and
carries the risk of interfering with what the compiler driver does. Just
let the gcc driver handle the details.

Clang/IAS is almost as straightforward, with the only additional edge
case being that for assembler files, DWARF 2 doesn't work, so the CFLAGS
is the same -gdwarf-N, but AFLAGS gets -gdwarf-N only if N > 2.

The messy case is only Clang/IAS=0, which needs to check the support
from the external assembler, and needs CFLAGS of -gdwarf-N and AFLAGS of
-Wa,--gdwarf-N, because Clang doesn't pass that option on to an external
assembler. This is why I was asking if the assembler support check can
be restricted to CC_IS_CLANG: nothing but Clang/IAS=0 actually requires
that check.

[Nick Desaulniers]

Oh, I see. Yeah, that might be a nicer approach. What should we do in
the case of gcc < 7 though, where -gdwarf-5 won't produce DWARF v5?
Maybe that's ok, but the intent behind the Kconfig check was to
prevent the option from being selectable if the tools do not support
it. Maybe it's more flexible to pass the arguments along, and hope
for the best?

As a gcc-5 user, I might be surprised if I chose
CONFIG_DEBUG_INFO_DWARF5 if what I got was not actually DWARF v5; it
does violate the principle of least surprise. Maybe that doesn't
matter though?
--
Thanks,
~Nick Desaulniers

[Arvind Sankar]

Even the current gcc documentation still says "DWARF Version 5 is only
experimental". If the user wants to try it out, I think it's fine to
let them get whatever subset their tool chain produces, as long as it's
not completely broken. Your latest help text does say that gcc 7+ is
required, maybe add another sentence saying that gcc 5+ only has partial
support for some draft DWARF 5 features?

Thanks.

[Sedat Dilek]

I have tested v3 on top of Linux v5.10.3 on Debian/testing AMD64.

Numbers talk - bullshit walks. [ Linus Torvalds ]

[ 5.10.3-1-amd64-gcc10-bfd ]

GNU-toolchain: GCC v10.2.1 and GNU/ld BFD v2.35.1

503096 vmlinux
6864 vmlinux.compressed
580104 vmlinux.o

701856 linux-image-5.10.3-1-amd64-gcc10-bfd-dbg_5.10.3-1~bullseye+dileks1_amd64.deb

[ 5.10.3-1-amd64-clang-ias ]

LLVM-toolchain: Clang and LLD v11.0.1-rc2

358424 vmlinux
7032 vmlinux.compressed
353788 vmlinux.o

508336 linux-image-5.10.3-1-amd64-clang-ias-dbg_5.10.3-1~bullseye+dileks1_amd64.deb

[ 5.10.3-1-amd64-gcc10-bfd ]

$ llvm-dwarfdump-11 vmlinux.o | head -15
error: vmlinux.o: file format elf64-x86-64

.debug_info contents:
decoding address ranges: invalid range list offset 0x265
0x00000000: Compile Unit: length = 0x0000001f, format = DWARF32,
version = 0x0005, unit_type = DW_UT_compile, abbr_offset = 0x0000,
addr_size = 0x08 (next unit at 0x00
000023)

0x0000000c: DW_TAG_compile_unit
DW_AT_stmt_list (0x00000000)
DW_AT_ranges (0x0000000c
[0x0000000000000000, 0x000000000000021c)
[0x0000000000000000, 0x000000000000019e)
[0x0000000000000000, 0x0000000000002000))
DW_AT_name ("head_64.S")
DW_AT_comp_dir ("/home/dileks/src/linux-kernel/git")
DW_AT_producer ("GNU AS 2.35.1")
DW_AT_language (DW_LANG_Mips_Assembler)

[ 5.10.3-1-amd64-clang-ias ]

$ llvm-dwarfdump-11 vmlinux.o | head -15
vmlinux.o: file format elf64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000377, format = DWARF32,
version = 0x0005, unit_type = DW_UT_compile, abbr_offset = 0x0000,
addr_size = 0x08 (next unit at 0x00
00037b)

0x0000000c: DW_TAG_compile_unit
DW_AT_stmt_list (0x00000000)
DW_AT_ranges (0x0000000c
[0x0000000000000000, 0x0000000000002000)
[0x0000000000000000, 0x000000000000021c)
[0x0000000000000000, 0x000000000000019e))
DW_AT_name ("arch/x86/kernel/head_64.S")
DW_AT_comp_dir ("/home/dileks/src/linux-kernel/git")
DW_AT_producer ("Debian clang version 11.0.1-+rc2-1")
DW_AT_language (DW_LANG_Mips_Assembler)

Attached are my kernel config files.

Feel free to add my:

Tested-by: Sedat Dilek <sedat...@gmail.com>

- sed@ -

> > Nick Desaulniers (2):
> > Kbuild: make DWARF version a choice
> > Kbuild: implement support for DWARF v5
> >
> > Makefile | 15 +++++++------
> > include/asm-generic/vmlinux.lds.h | 6 +++++-
> > lib/Kconfig.debug | 35 ++++++++++++++++++++++++++-----
> > scripts/test_dwarf5_support.sh | 9 ++++++++
> > 4 files changed, 53 insertions(+), 12 deletions(-)
> > create mode 100755 scripts/test_dwarf5_support.sh
> >
> > --
> > 2.29.2.576.ga3fc446d84-goog
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdkZEiHK01OD420USb0j%3DF0LcrnRbauv9Yw26tu-GRbYkg%40mail.gmail.com.

[Sedat Dilek]

Some more numbers with Linux v5.11-rc1 and identical GNU and LLVM toolchains.

[ 5.11.0-rc1-1-amd64-gcc10-bfd ]

492 vmlinux
7 vmlinux.compressed
567 vmlinux.o
685 linux-image-5.11.0-rc1-1-amd64-gcc10-bfd-dbg_5.11.0~rc1-1~bullseye+dileks1_amd64.deb

[ 5.11.0-rc1-2-amd64-clang-ias ]

350 vmlinux
7 vmlinux.compressed
345 vmlinux.o
495 linux-image-5.11.0-rc1-2-amd64-clang-ias-dbg_5.11.0~rc1-2~bullseye+dileks1_amd64.deb

- Sedat -

[Sedat Dilek]

[ ... ]

Some more numbers with Linux v5.10.4.

GCC v10.2.1
GNU/ld BFDd v2.35.1
LLD v11.0.1-rc2
LLVM toolchain v11.0.1-rc2

So using GCC with LLD together with DWARF v5 reduces the binary sizes.

Looks like Gmail makes the tabella look ugly...

| gcc10-bfd | gcc10-lld | gcc10-llvm | clang-ias
----------------------------------------------------------
vmlinux.o | 580212 | 504508 | 504508 | 353864
----------------------------------------------------------
vmlinux | 503172 | 509944 | 509944 | 358500
----------------------------------------------------------
dbg deb | 701576 | 606348 | 607656 | 506816

...so I add the lines below.

580212 5.10.4-1-amd64-gcc10-bfd/vmlinux.o
504508 5.10.4-2-amd64-gcc10-lld/vmlinux.o
504508 5.10.4-3-amd64-gcc10-llvm/vmlinux.o
353864 5.10.4-4-amd64-clang-ias/vmlinux.o

503172 5.10.4-1-amd64-gcc10-bfd/vmlinux
509944 5.10.4-2-amd64-gcc10-lld/vmlinux
509944 5.10.4-3-amd64-gcc10-llvm/vmlinux
358500 5.10.4-4-amd64-clang-ias/vmlinux

701576 5.10.4-1-amd64-gcc10-bfd/linux-image-5.10.4-1-amd64-gcc10-bfd-dbg_5.10.4-1~bullseye+dileks1_amd64.deb
606348 5.10.4-2-amd64-gcc10-lld/linux-image-5.10.4-2-amd64-gcc10-lld-dbg_5.10.4-2~bullseye+dileks1_amd64.deb
607656 5.10.4-3-amd64-gcc10-llvm/linux-image-5.10.4-3-amd64-gcc10-llvm-dbg_5.10.4-3~bullseye+dileks1_amd64.deb
506816 5.10.4-4-amd64-clang-ias/linux-image-5.10.4-4-amd64-clang-ias-dbg_5.10.4-4~bullseye+dileks1_amd64.deb

- Sedat -

[Nathan Chancellor]

On Thu, Dec 03, 2020 at 05:11:26PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions more straightforward.
>
> Suggested-by: Fangrui Song <mas...@google.com>
> Suggested-by: Masahiro Yamada <masa...@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesau...@google.com>

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

[Nathan Chancellor]

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

[Sedat Dilek]

On Fri, Dec 4, 2020 at 2:11 AM 'Nick Desaulniers' via Clang Built
Linux <clang-bu...@googlegroups.com> wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> DWARF5 wins significantly in terms of size when mixed with compression
> (CONFIG_DEBUG_INFO_COMPRESSED).
>

Is this patchset bulletproof with CONFIG_DEBUG_INFO_BTF=y (and clang-cfi)?

Debian has enabled this Kconfig in recent Linux v5.10 kernels which is
a base for my custom kernels.

It was fu**ing annoying to see I have no pahole binary installed and
my build got broken after 3 hours of build.
OK, I see that requirements is coded in scripts/link-vmlinux.sh.

I needed to install dwarves package which provides pahole binary.

I would like to see a prereq-checking for needed binaries with certain
Kconfig set.

After I calmed down I will - maybe - write to linux-kbuild mailing-list.
Hope this will be a friendly email.

- Sedat -

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201204011129.2493105-3-ndesaulniers%40google.com.

[Nathan Chancellor]

On Mon, Jan 11, 2021 at 09:27:48AM +0100, Sedat Dilek wrote:
> Is this patchset bulletproof with CONFIG_DEBUG_INFO_BTF=y (and clang-cfi)?
>
> Debian has enabled this Kconfig in recent Linux v5.10 kernels which is
> a base for my custom kernels.
>
> It was fu**ing annoying to see I have no pahole binary installed and
> my build got broken after 3 hours of build.
> OK, I see that requirements is coded in scripts/link-vmlinux.sh.
>
> I needed to install dwarves package which provides pahole binary.
>
> I would like to see a prereq-checking for needed binaries with certain
> Kconfig set.

Good idea, I have sent
https://lore.kernel.org/r/20210111180609.7139...@gmail.com

Cheers,
Nathan

[Sedat Dilek]

Great, thanks! 

[Sedat Dilek]

On Mon, Jan 11, 2021 at 9:27 AM Sedat Dilek <sedat...@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 2:11 AM 'Nick Desaulniers' via Clang Built
> Linux <clang-bu...@googlegroups.com> wrote:
> >
> > DWARF v5 is the latest standard of the DWARF debug info format.
> >
> > DWARF5 wins significantly in terms of size when mixed with compression
> > (CONFIG_DEBUG_INFO_COMPRESSED).
> >
>
> Is this patchset bulletproof with CONFIG_DEBUG_INFO_BTF=y (and clang-cfi)?
>
> Debian has enabled this Kconfig in recent Linux v5.10 kernels which is
> a base for my custom kernels.
>
> It was fu**ing annoying to see I have no pahole binary installed and
> my build got broken after 3 hours of build.
> OK, I see that requirements is coded in scripts/link-vmlinux.sh.
>
> I needed to install dwarves package which provides pahole binary.
>
> I would like to see a prereq-checking for needed binaries with certain
> Kconfig set.
>
> After I calmed down I will - maybe - write to linux-kbuild mailing-list.
> Hope this will be a friendly email.
>

After linux-bpf folks recommended not to use LLVM I jumped to gcc-10.

I tried with ld.bfd first and then in a next run with LLVM=1.

Upgraded pahole binary to latest Git plus a recommended patch from
linux-btf folks.

Unfortunately, I see with CONFIG_DEBUG_INFO_DWARF5=y and
CONFIG_DEBUG_INFO_BTF=y:

die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x3f0dd5a> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x3f0dd69> not handled!

In /usr/include/dwarf.h I found:

498: DW_OP_lit24 = 0x48, /* Literal 24. *

Can someone enlighten what is going on?

Nick, Fangrui?

Thanks.

- Sedat -

P.S.: Patch from linux-bpf

link="https://lore.kernel.org/bpf/20210112194724.GB1291051@krava/T/#t"
b4 -d am $link

- EOT -

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a cleanup from Masahiro and isn't DWARF v5 specific.
Patch 2 is a cleanup that lays the ground work and isn't DWARF
v5 specific.
Patch 3 implements Kconfig and Kbuild support for DWARFv5.

Changes from v3:

Changes as per Arvind:
* only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
* add -gdwarf-5 to Kconfig shell script.
* only run Kconfig shell script for Clang.

Apologies to Sedat and Nathan; I appreciate previous testing/review, but
I did no carry forward your Tested-by and Reviewed-by tags, as the
patches have changed too much IMO.

Changes from v2:
* Drop two of the earlier patches that have been accepted already.
* Add measurements with GCC 10.2 to commit message.
* Update help text as per Arvind with help from Caroline.
* Improve case/wording between DWARF Versions as per Masahiro.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

Masahiro Yamada (1):
Remove $(cc-option,-gdwarf-4) dependency from CONFIG_DEBUG_INFO_DWARF4

Nick Desaulniers (2):
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 15 +++++++----

include/asm-generic/vmlinux.lds.h | 6 ++++-
lib/Kconfig.debug | 41 +++++++++++++++++++++++++------
scripts/test_dwarf5_support.sh | 9 +++++++
4 files changed, 58 insertions(+), 13 deletions(-)

create mode 100755 scripts/test_dwarf5_support.sh

--

2.30.0.284.gd98b1dd5eaa7-goog

[Nick Desaulniers]

From: Masahiro Yamada <masa...@kernel.org>

The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.

You can see it at https://godbolt.org/z/6ed1oW

For gcc 4.5.3 pane, line 37: .value 0x4
For clang 10.0.1 pane, line 117: .short 4

Given Documentation/process/changes.rst stating GCC 4.9 is the minimal
version, this cc-option is unneeded.

Note
----

CONFIG_DEBUG_INFO_DWARF4 controls the DWARF version only for C files.

As you can see in the top Makefile, -gdwarf-4 is only passed to CFLAGS.

ifdef CONFIG_DEBUG_INFO_DWARF4
DEBUG_CFLAGS += -gdwarf-4
endif

This flag is used when compiling *.c files.

On the other hand, the assembler is always given -gdwarf-2.

KBUILD_AFLAGS += -Wa,-gdwarf-2

Hence, the debug info that comes from *.S files is always DWARF v2.
This is simply because GAS supported only -gdwarf-2 for a long time.

Recently, GAS gained the support for --dwarf-[3|4|5] options. [1]
And, also we have Clang integrated assembler. So, the debug info
for *.S files might be improved if we want.

In my understanding, the current code is intentional, not a bug.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31bf18645d98b4d3d7357353be840e320649a67d

Signed-off-by: Masahiro Yamada <masa...@kernel.org>
Reviewed-by: Nick Desaulniers <ndesau...@google.com>
---
lib/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 78361f0abe3a..dd7d8d35b2a5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -258,7 +258,6 @@ config DEBUG_INFO_SPLIT

config DEBUG_INFO_DWARF4
bool "Generate dwarf4 debuginfo"
- depends on $(cc-option,-gdwarf-4)
help

Generate dwarf4 debug info. This requires recent versions

of gcc and gdb. It makes the debug information larger.
--
2.30.0.284.gd98b1dd5eaa7-goog

[Nick Desaulniers]

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.

Suggested-by: Fangrui Song <mas...@google.com>

Suggested-by: Masahiro Yamada <masa...@kernel.org>
Signed-off-by: Nick Desaulniers <ndesau...@google.com>

---
Makefile | 14 +++++++++-----
lib/Kconfig.debug | 21 ++++++++++++++++-----
2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index d49c3f39ceb4..656fff17b331 100644
--- a/Makefile
+++ b/Makefile
@@ -826,12 +826,16 @@ else

DEBUG_CFLAGS += -g
endif

-ifneq ($(LLVM_IAS),1)
-KBUILD_AFLAGS += -Wa,-gdwarf-2

+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
+ifneq ($(dwarf-version-y)$(LLVM_IAS),21)

+# Binutils 2.35+ required for -gdwarf-4+ support.
+dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
+ifdef CONFIG_CC_IS_CLANG
+DEBUG_CFLAGS += $(dwarf-aflag)

endif
-
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS += -gdwarf-4

+KBUILD_AFLAGS += $(dwarf-aflag)
endif

ifdef CONFIG_DEBUG_INFO_REDUCED

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index dd7d8d35b2a5..e80770fac4f0 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,13 +256,24 @@ config DEBUG_INFO_SPLIT

to know about the .dwo files and include them.
Incompatible with older versions of ccache.

+choice
+ prompt "DWARF version"
+ help
+ Which version of DWARF debug info to emit.
+
+config DEBUG_INFO_DWARF2

+ bool "Generate DWARF Version 2 debuginfo"
+ help

+ Generate DWARF v2 debug info.
+
config DEBUG_INFO_DWARF4
- bool "Generate dwarf4 debuginfo"

+ bool "Generate DWARF Version 4 debuginfo"

help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly

+ improves the success of resolving variables in gdb on optimized code.
+
+endchoice # "DWARF version"

config DEBUG_INFO_BTF

bool "Generate BTF typeinfo"
--

2.30.0.284.gd98b1dd5eaa7-goog

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support. GNU `as` only recently gained support for specifying
-gdwarf-5.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head -n 4 | grep version
or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

Suggested-by: Fangrui Song <mas...@google.com>
Suggested-by: Caroline Tice <cmt...@google.com>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 1 +
include/asm-generic/vmlinux.lds.h | 6 +++++-

lib/Kconfig.debug | 17 +++++++++++++++++
scripts/test_dwarf5_support.sh | 9 +++++++++
4 files changed, 32 insertions(+), 1 deletion(-)
create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index 656fff17b331..1067cfd98249 100644
--- a/Makefile
+++ b/Makefile

@@ -828,6 +828,7 @@ endif

dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
ifneq ($(dwarf-version-y)$(LLVM_IAS),21)

# Binutils 2.35+ required for -gdwarf-4+ support.

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 49944f00d2b3..37dc4110875e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -843,7 +843,11 @@

.debug_types 0 : { *(.debug_types) } \
/* DWARF 5 */ \
.debug_macro 0 : { *(.debug_macro) } \
- .debug_addr 0 : { *(.debug_addr) }
+ .debug_addr 0 : { *(.debug_addr) } \
+ .debug_line_str 0 : { *(.debug_line_str) } \
+ .debug_loclists 0 : { *(.debug_loclists) } \
+ .debug_rnglists 0 : { *(.debug_rnglists) } \
+ .debug_str_offsets 0 : { *(.debug_str_offsets) }

/* Stabs debugging sections. */
#define STABS_DEBUG \

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e80770fac4f0..60a4f5e27ada 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -273,6 +273,23 @@ config DEBUG_INFO_DWARF4

It makes the debug information larger, but it significantly

improves the success of resolving variables in gdb on optimized code.

+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF Version 5 debuginfo"

+ depends on GCC_VERSION >= 50000 || CC_IS_CLANG
+ depends on CC_IS_GCC || $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
+ help
+ Generate DWARF v5 debug info. Requires binutils 2.35, gcc 5.0+ (gcc
+ 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
+ draft features until 7.0), and gdb 8.0+.
+
+ Changes to the structure of debug info in Version 5 allow for around
+ 15-18% savings in resulting image and debug info section sizes as
+ compared to DWARF Version 4. DWARF Version 5 standardizes previous

+ extensions such as accelerators for symbol indexing and the format

+ for fission (.dwo/.dwp) files. Users may not want to select this
+ config if they rely on tooling that has not yet been updated to
+ support DWARF Version 5.
+

endchoice # "DWARF version"

config DEBUG_INFO_BTF

diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
new file mode 100755

index 000000000000..142a1b5c7fa2

--- /dev/null
+++ b/scripts/test_dwarf5_support.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
+# in binutils < 2.35.
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
+set -e

+echo '.file 0 "filename"' | $* -gdwarf-5 -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
--
2.30.0.284.gd98b1dd5eaa7-goog

[Nathan Chancellor]

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

[Nathan Chancellor]

On Tue, Jan 12, 2021 at 04:32:34PM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions more straightforward.
>
> Suggested-by: Fangrui Song <mas...@google.com>
> Suggested-by: Masahiro Yamada <masa...@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesau...@google.com>

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

[Nathan Chancellor]

One small nit below.

Reviewed-by: Nathan Chancellor <natecha...@gmail.com>

This is unnecessary, clang will error without this and a script's exit
code is the exit code of its last command.

[Sedat Dilek]

Why is that "ifdef CONFIG_CC_IS_CLANG"?
When I use GCC v10.2.1 DEBUG_CFLAGS are not set.

- Sedat -

[Caroline Tice]

There are multiple dwarf objects with the value 0x48, depending on which section of the dwarf.h file you search:

DW_TAG_call_site = 0x48

DW_AT_static_link = 0x48

DW_OP_lit24 = 0x48.

In this case, since the error message was about a DW_TAG, it would be complaining about DW_TAG_call_site, which is new to DWARR v5.

[Nick Desaulniers]

Sedat,
Thanks for testing, and congrats on https://lwn.net/Articles/839772/.
I always appreciate you taking the time to help test my work, and
other Clang+Linux kernel patches!

On Wed, Jan 13, 2021 at 1:24 PM Sedat Dilek <sedat...@gmail.com> wrote:
>
> On Wed, Jan 13, 2021 at 1:32 AM Nick Desaulniers
> <ndesau...@google.com> wrote:
> >
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -826,12 +826,16 @@ else
> > DEBUG_CFLAGS += -g
> > endif
> >
> > -ifneq ($(LLVM_IAS),1)
> > -KBUILD_AFLAGS += -Wa,-gdwarf-2
> > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)

^ DEBUG_CFLAGS are set for everyone (all toolchains) if
CONFIG_DEBUG_INFO is defined.

> > +ifneq ($(dwarf-version-y)$(LLVM_IAS),21)

^ "If not using dwarf 2 and LLVM_IAS=1", ie. CONFIG_DEBUG_INFO_DWARF5
&& CONFIG_CC_IS_GCC

> > +# Binutils 2.35+ required for -gdwarf-4+ support.
> > +dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> > +ifdef CONFIG_CC_IS_CLANG

^ "if clang"

> > +DEBUG_CFLAGS += $(dwarf-aflag)
> > endif
>
> Why is that "ifdef CONFIG_CC_IS_CLANG"?

That's what Arvind requested on v2, IIUC:
https://lore.kernel.org/lkml/X8psgMuL4jMjP%2F...@rani.riverdale.lan/

> When I use GCC v10.2.1 DEBUG_CFLAGS are not set.

You should have -gdwarf-4 (and not -Wa,-gwarf-4) set for DEBUG_CFLAGS
when compiling with GCC and enabling CONFIG_DEBUG_INFO_DWARF4. Can you
please confirm? (Perhaps you may have accidentally disabled
CONFIG_DEBUG_INFO by rerunning `make defconfig`?)
--
Thanks,
~Nick Desaulniers

[Sedat Dilek]

[ CC linux-bpf & Andrii and Jiri ]

Thanks for your feedback Caroline.

I ran several builds in the last 24 hours with Linux v5.11-rc3.

Setting DWARF version 2 (CONFIG_DEBUG_INFO_DWARF2=y) or version 4
(CONFIG_DEBUG_INFO_DWARF4=y) with this patchset together with GCC
v10.2.1 plus LLVM=1 does NOT show this.
BTW, it does not matter when LLVM/Clang v12 and LLVM/Clang v11 is used.
But again my compiler is here GCC plus LLVM utils like llvm-objcopy,
ld.lld, lllvm-ar, llvm-nm, etc.
( My initial problem was also seen with Clang v11.0.1 - I switched to
GCC as Debian's linux-kernel uses CONFIG_DEBUG_INFO_BTF=y
successfully. )

So, this is definitely a DWARF version 5 issue when
CONFIG_DEBUG_INFO_BTF=y (and CONFIG_DEBUG_INFO_BTF_MODULES=y).

Furthermore, my build-log says with pahole (see post-scriptum) from
dwarves package - here as an example:

WARN: multiple IDs found for 'bpf_map': 3860, 369255 - using 3860

$ grep 'WARN: multiple IDs found for'
build-log_5.11.0-rc3-6-amd64-gcc10-llvm11.txt | wc -l
1621

In the Linux code this derives from tools/bpf/resolve_btfids:

static int symbols_resolve(struct object *obj)
...
pr_info("WARN: multiple IDs found for
'%s': %d, %d - using %d\n",

( Cut-n-paste into Gmail truncates the lines and indentation, so I dropped it. )

Please see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/resolve_btfids/main.c#n469
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/resolve_btfids/main.c#n532

I looked with llvm-dwarf tool and saw some errors concerning
".debug-ranges" (cannot remember the exact output and the command-line
I used).

Example for "DW_TAG_INVALID (0x48)" from my build-log:

die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x1f671e7> not handled!

$ llvm-dwarfdump-11 --debug-info=0x1f671e7 vmlinux
vmlinux: file format elf64-x86-64

.debug_info contents:

0x01f671e7: DW_TAG_call_site
DW_AT_call_return_pc (0xffffffff811b16f2)
DW_AT_call_origin (0x01f67f1d)

Looking for "DW_AT_call_origin (0x01f67f1d)":

$ llvm-dwarfdump-11 --debug-info=0x01f67f1d vmlinux
vmlinux: file format elf64-x86-64

.debug_info contents:

0x01f67f1d: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_linkage_name ("fput")
DW_AT_name ("fput")
DW_AT_decl_file
("/home/dileks/src/linux-kernel/git/./include/linux/file.h")
DW_AT_decl_line (16)
DW_AT_decl_column (0x0d)

I have no experience in digging into DWARF (version 5) issues and how
to use llvm-dwarf or another appropriate tool.
If you give me a hand...
So all the above says - to be honest - nothing to me.
I hope it says something to you experts.

Regards,
- Sedat -

P.S.: I tried with a selfmade pahole from latest Git plus Jiri's v2
patch of "btf_encoder: Add extra checks for symbol names".

link="https://lore.kernel.org/bpf/20210113102509....@kernel.org/T/#t
b4 -d am $link
...
Wrote v2_20210113_jolsa_btf_encoder_add_extra_checks_for_symbol_names.am
for thanks tracking

[1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/

[Sedat Dilek]

I have to correct myself:
The used assembler within my GCC experiments is GNU/ld BFD version
v2.35.1 - not LLD linker!

- Sedat -

[Sedat Dilek]

On Thu, Jan 14, 2021 at 12:27 AM Nick Desaulniers
<ndesau...@google.com> wrote:
>
> Sedat,
> Thanks for testing, and congrats on https://lwn.net/Articles/839772/.
> I always appreciate you taking the time to help test my work, and
> other Clang+Linux kernel patches!
>

Hi Nick,

cool, again in the top 15 :-).

I should ask Mr. Corbet for a LWN subscription.

> On Wed, Jan 13, 2021 at 1:24 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >
> > On Wed, Jan 13, 2021 at 1:32 AM Nick Desaulniers
> > <ndesau...@google.com> wrote:
> > >
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -826,12 +826,16 @@ else
> > > DEBUG_CFLAGS += -g
> > > endif
> > >
> > > -ifneq ($(LLVM_IAS),1)
> > > -KBUILD_AFLAGS += -Wa,-gdwarf-2
> > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
>
> ^ DEBUG_CFLAGS are set for everyone (all toolchains) if
> CONFIG_DEBUG_INFO is defined.
>
> > > +ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
>
> ^ "If not using dwarf 2 and LLVM_IAS=1", ie. CONFIG_DEBUG_INFO_DWARF5
> && CONFIG_CC_IS_GCC
>

OK, I know DWARF v2 and LLVM_IAS=1 is broken.

Looks like DWARF v5 with GCC v10.2.1 and binutils v2.35.1 is currently
(here) no good choice.

> > > +# Binutils 2.35+ required for -gdwarf-4+ support.
> > > +dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> > > +ifdef CONFIG_CC_IS_CLANG
>
> ^ "if clang"
>
> > > +DEBUG_CFLAGS += $(dwarf-aflag)
> > > endif
> >
> > Why is that "ifdef CONFIG_CC_IS_CLANG"?
>
> That's what Arvind requested on v2, IIUC:
> https://lore.kernel.org/lkml/X8psgMuL4jMjP%2F...@rani.riverdale.lan/
>
> > When I use GCC v10.2.1 DEBUG_CFLAGS are not set.
>
> You should have -gdwarf-4 (and not -Wa,-gwarf-4) set for DEBUG_CFLAGS
> when compiling with GCC and enabling CONFIG_DEBUG_INFO_DWARF4. Can you
> please confirm? (Perhaps you may have accidentally disabled
> CONFIG_DEBUG_INFO by rerunning `make defconfig`?)
>

$ egrep 'CC_IS_|LD_IS|BTF|DWARF'
config-5.11.0-rc3-5-amd64-gcc10-llvm11 | grep ^CONFIG
CONFIG_CC_IS_GCC=y
CONFIG_LD_IS_LLD=y
CONFIG_DEBUG_INFO_DWARF4=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y

$ grep '\-Wa,-gdwarf-4' build-log_5.11.0-rc3-5-amd64-gcc10-llvm11.txt
| wc -l
156

[Sedat Dilek]

I wonder why I see GNU/as here (see above CONFIG_LD_IS_LLD=y)?

$ llvm-dwarfdump-11 vmlinux | head -20 | egrep
'debug_info|format|version|DW_AT_producer'

vmlinux: file format elf64-x86-64
.debug_info contents:

0x00000000: Compile Unit: length = 0x0000001e, format = DWARF32,
version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at
0x00000022)

DW_AT_producer ("GNU AS 2.35.1")

0x00000022: Compile Unit: length = 0x0000c1d2, format = DWARF32,
version = 0x0004, abbr_offset = 0x0012, addr_size = 0x08 (next unit at
0x0000c1f8)
DW_AT_producer ("GNU C89 10.2.1 20210110 -mno-sse
-mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary
=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel
-mindirect-branch=thunk-extern -mindirect-branch-register
-mrecord-mcount -mfentry -march=x86-64 -g -g
dwarf-4 -O2 -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar
-fno-PIE -falign-jumps=1 -falign-loops=1
-fno-asynchronous-unwind-tables -fno-jump-tables -fno-de
lete-null-pointer-checks -fno-allow-store-data-races
-fstack-protector-strong -fno-strict-overflow -fstack-check=no
-fconserve-stack -fcf-protection=none -fno-stack-pr
otector")

Maybe, I should set all LLVM utils and linker manually, not using LLVM=1.

- Sedat -

[Sedat Dilek]

I found in my archives:

[ error: decoding address ranges: ]

Looks like these DW_TAG_xxx are involved.

$ egrep -B4 -n 'error: decoding address ranges:' llvm-dwarfdump.txt |
grep DW_TAG_ | awk '{ print $2 }' | sort | uniq
DW_TAG_compile_unit
DW_TAG_formal_parameter
DW_TAG_inlined_subroutine
DW_TAG_lexical_block
DW_TAG_subprogram

[ example ]

1017373-0x001a1691: DW_TAG_compile_unit
1017374- DW_AT_producer ("GNU C89 10.2.1 20210110

-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-
boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone
-mcmodel=kernel -mindirect-branch=thunk-extern
-mindirect-branch-register -mrecord-mcount -mfentry -march=x86-

64 -g -gdwarf-5 -O2 -std=gnu90 -p -fno-strict-aliasing -fno-common

-fshort-wchar -fno-PIE -falign-jumps=1 -falign-loops=1
-fno-asynchronous-unwind-tables -fno-jump-tab
les -fno-delete-null-pointer-checks -fno-allow-store-data-races
-fstack-protector-strong -fno-strict-overflow -fstack-check=no

-fconserve-stack -fcf-protection=none")
1017375- DW_AT_language (DW_LANG_C11)
1017376- DW_AT_name ("arch/x86/events/intel/knc.c")
1017377- DW_AT_comp_dir ("/home/dileks/src/linux-kernel/git")
1017378: DW_AT_ranges (0x000080d8error: decoding
address ranges: invalid range list offset 0x80d8
1017379-)
1017380- DW_AT_low_pc (0x0000000000000000)
1017381- DW_AT_stmt_list (0x000298ec)
1017382-

Furthermore I see <decoding error>.

[ example <decoding error> ]

1016826-0x001a131b: DW_TAG_formal_parameter
1016827- DW_AT_abstract_origin (0x0019dacd "event")
1016828- DW_AT_location (0x00020eff:
1016829: [0xffffffff8100f9c0, 0xffffffff8100fa76):
<decoding error> fa 37 3e 01 00 9f)
1016830- DW_AT_unknown_2137 (0x00020efd)

- Sedat -

[Nick Desaulniers]

On Wed, Jan 13, 2021 at 10:18 PM Sedat Dilek <sedat...@gmail.com> wrote:
>
> On Wed, Jan 13, 2021 at 11:25 PM Caroline Tice <cmt...@google.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 3:17 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >>
> >> Unfortunately, I see with CONFIG_DEBUG_INFO_DWARF5=y and
> >> CONFIG_DEBUG_INFO_BTF=y:
> >>
> >> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x3f0dd5a> not handled!
> >> die__process_function: DW_TAG_INVALID (0x48) @ <0x3f0dd69> not handled!

I can confirm that I see a stream of these warnings when building with
this patch series applied, and those two configs enabled.

rebuilding with `make ... V=1`, it looks like the call to:

+ pahole -J .tmp_vmlinux.btf

is triggering these.

Shall I send a v4 that adds a Kconfig dependency on !DEBUG_INFO_BTF?
Does pahole have a bug tracker?

> >>
> >> In /usr/include/dwarf.h I found:
> >>
> >> 498: DW_OP_lit24 = 0x48, /* Literal 24. *
> >
> >
> > There are multiple dwarf objects with the value 0x48, depending on which section of the dwarf.h file you search:
> >
> > DW_TAG_call_site = 0x48
> > DW_AT_static_link = 0x48
> > DW_OP_lit24 = 0x48.
> >

> > In this case, since the error message was about a DW_TAG, it would be complaining about DW_TAG_call_site, which is new to DWARF v5.

> >
> Example for "DW_TAG_INVALID (0x48)" from my build-log:
>
> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x1f671e7> not handled!
>
> $ llvm-dwarfdump-11 --debug-info=0x1f671e7 vmlinux
> vmlinux: file format elf64-x86-64
>
> .debug_info contents:
>
> 0x01f671e7: DW_TAG_call_site
> DW_AT_call_return_pc (0xffffffff811b16f2)
> DW_AT_call_origin (0x01f67f1d)
>
> Looking for "DW_AT_call_origin (0x01f67f1d)":
>
> $ llvm-dwarfdump-11 --debug-info=0x01f67f1d vmlinux
> vmlinux: file format elf64-x86-64
>
> .debug_info contents:
>
> 0x01f67f1d: DW_TAG_subprogram
> DW_AT_external (true)
> DW_AT_declaration (true)
> DW_AT_linkage_name ("fput")
> DW_AT_name ("fput")
> DW_AT_decl_file
> ("/home/dileks/src/linux-kernel/git/./include/linux/file.h")
> DW_AT_decl_line (16)
> DW_AT_decl_column (0x0d)

That's a neat trick (using --debug-info=offset to print one element
from the stream).
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Thu, Jan 14, 2021 at 10:53 AM Nick Desaulniers
<ndesau...@google.com> wrote:
>
> On Wed, Jan 13, 2021 at 10:18 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >
> > On Wed, Jan 13, 2021 at 11:25 PM Caroline Tice <cmt...@google.com> wrote:
> > >
> > > On Tue, Jan 12, 2021 at 3:17 PM Sedat Dilek <sedat...@gmail.com> wrote:
> > >>
> > >> Unfortunately, I see with CONFIG_DEBUG_INFO_DWARF5=y and
> > >> CONFIG_DEBUG_INFO_BTF=y:
> > >>
> > >> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x3f0dd5a> not handled!
> > >> die__process_function: DW_TAG_INVALID (0x48) @ <0x3f0dd69> not handled!
>
> I can confirm that I see a stream of these warnings when building with
> this patch series applied, and those two configs enabled.
>
> rebuilding with `make ... V=1`, it looks like the call to:
>
> + pahole -J .tmp_vmlinux.btf
>
> is triggering these.
>
> Shall I send a v4 that adds a Kconfig dependency on !DEBUG_INFO_BTF?
> Does pahole have a bug tracker?

FWIW, my distro packages pahole v1.17; rebuilt with ToT v1.19 from
source and also observe the issue.
--
Thanks,
~Nick Desaulniers

[Yonghong Song]

On 1/14/21 11:01 AM, Nick Desaulniers wrote:
> On Thu, Jan 14, 2021 at 10:53 AM Nick Desaulniers
> <ndesau...@google.com> wrote:
>>
>> On Wed, Jan 13, 2021 at 10:18 PM Sedat Dilek <sedat...@gmail.com> wrote:
>>>
>>> On Wed, Jan 13, 2021 at 11:25 PM Caroline Tice <cmt...@google.com> wrote:
>>>>
>>>> On Tue, Jan 12, 2021 at 3:17 PM Sedat Dilek <sedat...@gmail.com> wrote:
>>>>>
>>>>> Unfortunately, I see with CONFIG_DEBUG_INFO_DWARF5=y and
>>>>> CONFIG_DEBUG_INFO_BTF=y:
>>>>>
>>>>> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x3f0dd5a> not handled!
>>>>> die__process_function: DW_TAG_INVALID (0x48) @ <0x3f0dd69> not handled!
>>
>> I can confirm that I see a stream of these warnings when building with
>> this patch series applied, and those two configs enabled.
>>
>> rebuilding with `make ... V=1`, it looks like the call to:
>>
>> + pahole -J .tmp_vmlinux.btf
>>
>> is triggering these.
>>
>> Shall I send a v4 that adds a Kconfig dependency on !DEBUG_INFO_BTF?
>> Does pahole have a bug tracker?

pahole could have issues for dwarf5 since as far as I know, people just
use dwarf2/dwarf4 with config functions in the kernel.

Where is the link of the patch to add CONFIG_DEBUG_INFO_DWARF5 to linux?
I think you can add CONFIG_DEBUG_INFO_DWARF5 to kernel with dependency
of !CONFIG_DEBUG_INFO_BTF. At the same time, people can debug pahole
issues. Once it is resolved, !CONFIG_DEBUG_INFO_BTF dependency can be
removed with proper pahole version change in kernel.

[Nick Desaulniers]

On Thu, Jan 14, 2021 at 11:13 AM Yonghong Song <y...@fb.com> wrote:
>
>
>
> On 1/14/21 11:01 AM, Nick Desaulniers wrote:
> > On Thu, Jan 14, 2021 at 10:53 AM Nick Desaulniers
> > <ndesau...@google.com> wrote:
> >>
> >> On Wed, Jan 13, 2021 at 10:18 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >>>
> >>> On Wed, Jan 13, 2021 at 11:25 PM Caroline Tice <cmt...@google.com> wrote:
> >>>>
> >>>> On Tue, Jan 12, 2021 at 3:17 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >>>>>
> >>>>> Unfortunately, I see with CONFIG_DEBUG_INFO_DWARF5=y and
> >>>>> CONFIG_DEBUG_INFO_BTF=y:
> >>>>>
> >>>>> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x3f0dd5a> not handled!
> >>>>> die__process_function: DW_TAG_INVALID (0x48) @ <0x3f0dd69> not handled!
> >>
> >> I can confirm that I see a stream of these warnings when building with
> >> this patch series applied, and those two configs enabled.
> >>
> >> rebuilding with `make ... V=1`, it looks like the call to:
> >>
> >> + pahole -J .tmp_vmlinux.btf
> >>
> >> is triggering these.
> >>
> >> Shall I send a v4 that adds a Kconfig dependency on !DEBUG_INFO_BTF?
> >> Does pahole have a bug tracker?
>
> pahole could have issues for dwarf5 since as far as I know, people just
> use dwarf2/dwarf4 with config functions in the kernel.
>
> Where is the link of the patch to add CONFIG_DEBUG_INFO_DWARF5 to linux?

Latest is v4: https://lore.kernel.org/lkml/20210113003235.716...@google.com/

> I think you can add CONFIG_DEBUG_INFO_DWARF5 to kernel with dependency
> of !CONFIG_DEBUG_INFO_BTF. At the same time, people can debug pahole
> issues. Once it is resolved, !CONFIG_DEBUG_INFO_BTF dependency can be
> removed with proper pahole version change in kernel.

SGTM, will send a v5 tomorrow in case there's more feedback.

>
> >
> > FWIW, my distro packages pahole v1.17; rebuilt with ToT v1.19 from
> > source and also observe the issue.
> >

--
Thanks,
~Nick Desaulniers

[Sedat Dilek]

Yeah, sounds like a good idea.

- Sedat -

[Sedat Dilek]

On Thu, Jan 14, 2021 at 8:20 PM Nick Desaulniers

Please CC me on v5.

Feel free to add my Reported-by.

- Sedat -

[Sedat Dilek]

Today, I have observed and reported (see [1]) bpf/btf/pahole issues
with Clang v12 (from apt.llvm.org) and DWARF-4 ("four").
Cannot speak for other compilers and its version.

- Sedat -

[1] https://lore.kernel.org/bpf/CA+icZUWb3OyaSQAso8LhsRif...@mail.gmail.com/T/#m6d05cc6c634e9cee89060b2522abc78c3705ea4c

[Nick Desaulniers]

On Thu, Jan 14, 2021 at 1:52 PM Sedat Dilek <sedat...@gmail.com> wrote:
>
> Today, I have observed and reported (see [1]) bpf/btf/pahole issues
> with Clang v12 (from apt.llvm.org) and DWARF-4 ("four").
> Cannot speak for other compilers and its version.

If these are not specific to DWARF5, then it sounds like
CONFIG_DEBUG_INFO_DWARF4 should also be marked as `depends on
!DEBUG_INFO_BTF`? (or !BTF && CC=clang)

>
> - Sedat -
>
> [1] https://lore.kernel.org/bpf/CA+icZUWb3OyaSQAso8LhsRif...@mail.gmail.com/T/#m6d05cc6c634e9cee89060b2522abc78c3705ea4c

--
Thanks,
~Nick Desaulniers

[Sedat Dilek]

On Thu, Jan 14, 2021 at 11:05 PM Nick Desaulniers
<ndesau...@google.com> wrote:
>
> On Thu, Jan 14, 2021 at 1:52 PM Sedat Dilek <sedat...@gmail.com> wrote:
> >
> > Today, I have observed and reported (see [1]) bpf/btf/pahole issues
> > with Clang v12 (from apt.llvm.org) and DWARF-4 ("four").
> > Cannot speak for other compilers and its version.
>
> If these are not specific to DWARF5, then it sounds like
> CONFIG_DEBUG_INFO_DWARF4 should also be marked as `depends on
> !DEBUG_INFO_BTF`? (or !BTF && CC=clang)
>

My experiments yesterday on Wednesday were with GCC v10.2.1 plus LLVM=1.
There were no issues with DWARF v2 and v4 but v5.

Unfortunately, build-time is long here on my systems.

For now, I did CONFIG_DEBUG_INFO_BTF=n.

I have applied attached patch.

Is it possible to re-arrange CC depends?

[ /lib/Kconfig.debug ]

config DEBUG_INFO_DWARF5

bool "Generate DWARF Version 5 debuginfo"

- depends on GCC_VERSION >= 50000 || CC_IS_CLANG
- depends on CC_IS_GCC ||
$(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC)
$(CLANG_FLAGS))
+ depends on CC_IS_GCC && GCC_VERSION >= 50000 || CC_IS_CLANG
+ depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh
$(CC) $(CLANG_FLAGS))
+ depends on !DEBUG_INFO_BTF
help

Generate DWARF v5 debug info. Requires binutils 2.35, gcc 5.0+ (gcc

5.0+ accepts the -gdwarf-5 flag but only had partial support for some

And adding text to help concerning DEBUG_INFO_BTF is no good these days.

BTW, if you do not mind:

Label your patches with "*k*build:" not "*K*build:".

Use "DWARF *v*ersion" not "DWARF *V*ersion" - everywhere.

One patch missed the label "kbuild:" (guess the subject has too many
characters).

From what I remember - but these are small nits.

Thanks for DWARF v5 support in Linux.

- Sedat -

[Sedat Dilek]

On Wed, Jan 13, 2021 at 11:25 PM Caroline Tice <cmt...@google.com> wrote:
>
>
>
>
>

Hi,

this is with Clang v12 and LLVM=1 plus CONFIG_DEBUG_INFO_DWARF4=y
(version four not five) and CONFIG_DEBUG_BTF=y.

$ /usr/bin/clang-12 -v
Debian clang version
12.0.0-++20210113111128+3122c66aee7b-1~exp1~20210113101823.3720

Attaching the ERRORs.

+ llvm-objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
+ LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
...
ERRORs
...
+ llvm-objcopy --only-section=.BTF --set-section-flags
.BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o

Please let me know if this helps or not.

NOTE: I have archived all vmlinux and BTF-vmlinux files.

- Sedat -

[Yonghong Song]

Thanks, the above change looks good to me as well as the suggestion to
add some explanation why disabling DEBUG_INFO_BTF.

[Masahiro Yamada]

On Thu, Jan 14, 2021 at 8:27 AM Nick Desaulniers

If CONFIG_CC_IS_CLANG is set,
both -gdwarf and -Wa,-gdwarf-4 are passed to DEBUG_CFLAGS.

Is it necessary?



IIUC, -Wa,-gdwarf is meaningless
when you build *.c files.


I passed -v option to see
how gas is invoked behind the scene.


See the following results
for [1] GCC + GAS and [2] Clang + GAS cases




[1] GCC + GAS


masahiro@grover:~$ cat test.c
int main(void) { return 0; }
masahiro@grover:~$ gcc -v -gdwarf-4 -c -o test.o test.c
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.2.0-13ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-gdwarf-4' '-c' '-o' 'test.o'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1 -quiet -v -imultiarch
x86_64-linux-gnu test.c -quiet -dumpbase test.c -mtune=generic
-march=x86-64 -auxbase-strip test.o -gdwarf-4 -version
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection -o
/tmp/cc4hKJeo.s
GNU C17 (Ubuntu 10.2.0-13ubuntu1) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.2.0-rc1, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/10/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C17 (Ubuntu 10.2.0-13ubuntu1) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.2.0-rc1, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4831429547eb0be4fec215fca56ed5cf
COLLECT_GCC_OPTIONS='-v' '-gdwarf-4' '-c' '-o' 'test.o'
'-mtune=generic' '-march=x86-64'
as -v --64 -o test.o /tmp/cc4hKJeo.s
GNU assembler version 2.35.1 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.35.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-gdwarf-4' '-c' '-o' 'test.o'
'-mtune=generic' '-march=x86-64'
masahiro@grover:~$ readelf --debug-dump=info test.o
Contents of the .debug_info section:

Compilation Unit @ offset 0x0:
Length: 0x4f (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x16): GNU C17
10.2.0 -mtune=generic -march=x86-64 -gdwarf-4
-fasynchronous-unwind-tables -fstack-protector-strong
-fstack-clash-protection -fcf-protection
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0xf): test.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x0): /home/masahiro
<19> DW_AT_low_pc : 0x0
<21> DW_AT_high_pc : 0xf
<29> DW_AT_stmt_list : 0x0
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_external : 1
<2e> DW_AT_name : (indirect string, offset: 0xab): main
<32> DW_AT_decl_file : 1
<33> DW_AT_decl_line : 1
<34> DW_AT_decl_column : 5
<35> DW_AT_prototyped : 1
<35> DW_AT_type : <0x4b>
<39> DW_AT_low_pc : 0x0
<41> DW_AT_high_pc : 0xf
<49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<4b> DW_AT_GNU_all_call_sites: 1
<1><4b>: Abbrev Number: 3 (DW_TAG_base_type)
<4c> DW_AT_byte_size : 4
<4d> DW_AT_encoding : 5 (signed)
<4e> DW_AT_name : int
<1><52>: Abbrev Number: 0





[2] Clang + GAS

masahiro@grover:~$ clang -v -fno-integrated-as -gdwarf-4 -c -o test.o test.c
Ubuntu clang version 11.0.0-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/lib/llvm-11/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -S
-disable-free -disable-llvm-verifier -discard-value-names
-main-file-name test.c -mrelocation-model static -mframe-pointer=all
-fmath-errno -fno-rounding-math -no-integrated-as
-mconstructor-aliases -munwind-tables -target-cpu x86-64
-fno-split-dwarf-inlining -debug-info-kind=limited -dwarf-version=4
-debugger-tuning=gdb -v -resource-dir
/usr/lib/llvm-11/lib/clang/11.0.0 -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-11/lib/clang/11.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem
/usr/include -fno-dwarf-directory-asm -fdebug-compilation-dir
/home/masahiro -ferror-limit 19 -fgnuc-version=4.2.1
-fcolor-diagnostics -o /tmp/test-f43580.s -x c test.c
clang -cc1 version 11.0.0 based upon LLVM 11.0.0 default target
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/llvm-11/lib/clang/11.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/as" --64 -o test.o /tmp/test-f43580.s
masahiro@grover:~$ readelf --debug-dump=info test.o
Contents of the .debug_info section:

Compilation Unit @ offset 0x0:
Length: 0x47 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): Ubuntu
clang version 11.0.0-2
<10> DW_AT_language : 12 (ANSI C99)
<12> DW_AT_name : (indirect string, offset: 0x1e): test.c
<16> DW_AT_stmt_list : 0x0
<1a> DW_AT_comp_dir : (indirect string, offset: 0x25): /home/masahiro
<1e> DW_AT_low_pc : 0x0
<26> DW_AT_high_pc : 0xf
<1><2a>: Abbrev Number: 2 (DW_TAG_subprogram)
<2b> DW_AT_low_pc : 0x0
<33> DW_AT_high_pc : 0xf
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name : (indirect string, offset: 0x34): main
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 1
<3f> DW_AT_prototyped : 1
<3f> DW_AT_type : <0x43>
<43> DW_AT_external : 1
<1><43>: Abbrev Number: 3 (DW_TAG_base_type)
<44> DW_AT_name : (indirect string, offset: 0x39): int
<48> DW_AT_encoding : 5 (signed)
<49> DW_AT_byte_size : 4
<1><4a>: Abbrev Number: 0






In [1], "as -v --64 -o test.o /tmp/cc4hKJeo.s"
is the command that invoked gas.

There is no -gdwarf-4 option passed to gas here,
but the produced object has the correct dwarf4 info.




In [2], "/usr/bin/as" --64 -o test.o /tmp/test-f43580.s
is the command that invoked gas.

Again, no -gdwarf-4 option here,
but the produced object has the correct dwarf4 info.




So, when you build *.c -> *.o,
passing -gdwarf-* is enough.

The debug info is generated in the compile stage (i.e. by cc1)
and included in the intermediate /tmp/*.s file.

All gas needs to do is to transform the debug sections
in the intermediate /tmp/*.s file
into the binary stream in the .o file.
GAS does it without being instructed by the
explicit -Wa,-gdwarf-* option.


In my understanding, passing -Wa,-gdwarf
makes sense only when you build *.S -> *.o


This is why I think
DEBUG_CFLAGS += -gdwarf-4 (for source debug of .c files)
and
KBUILD_AFLAGS += -Wa,gdwarf-4 (for source debug of .S files)

are basically orthogonal (and they can be even controlled by
separate CONFIG options).


As stated above, DEBUG_CFLAGS += -Wa,gdward-4
does not make sense.


I am not a compiler expert, but
that is what I understood from some experiments.

Please correct me if I am wrong.

> > When I use GCC v10.2.1 DEBUG_CFLAGS are not set.
>
> You should have -gdwarf-4 (and not -Wa,-gwarf-4) set for DEBUG_CFLAGS
> when compiling with GCC and enabling CONFIG_DEBUG_INFO_DWARF4. Can you
> please confirm? (Perhaps you may have accidentally disabled
> CONFIG_DEBUG_INFO by rerunning `make defconfig`?)
> --
> Thanks,
> ~Nick Desaulniers

--
Best Regards


Masahiro Yamada

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a cleanup from Masahiro and isn't DWARF v5 specific.
Patch 2 is a cleanup that lays the ground work and isn't DWARF
v5 specific.
Patch 3 implements Kconfig and Kbuild support for DWARFv5.

Changes from v4:
* drop set -e from script as per Nathan.
* add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat.
* Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and
Masahiro. Sorry it took me a few tries to understand the point (I
might still not), but it looks much cleaner this way. Sorry Nathan, I
did not carry forward your previous reviews as a result, but I would
appreciate if you could look again.
* Add Nathan's reviewed by tag to patch 1.
* Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5
binutils addition later, and BTF issue.
* I still happen to see a pahole related error spew for the combination
of:
* LLVM=1
* LLVM_IAS=1
* CONFIG_DEBUG_INFO_DWARF4
* CONFIG_DEBUG_INFO_BTF
Though they're non-fatal to the build. I'm not sure yet why removing
any one of the above prevents the warning spew. Maybe we'll need a v6.

Changes from v3:

Changes as per Arvind:
* only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
* add -gdwarf-5 to Kconfig shell script.
* only run Kconfig shell script for Clang.

Apologies to Sedat and Nathan; I appreciate previous testing/review, but
I did no carry forward your Tested-by and Reviewed-by tags, as the
patches have changed too much IMO.

Changes from v2:
* Drop two of the earlier patches that have been accepted already.
* Add measurements with GCC 10.2 to commit message.
* Update help text as per Arvind with help from Caroline.
* Improve case/wording between DWARF Versions as per Masahiro.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

*** BLURB HERE ***

Masahiro Yamada (1):
Remove $(cc-option,-gdwarf-4) dependency from CONFIG_DEBUG_INFO_DWARF4

Nick Desaulniers (2):
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 13 +++++++---
include/asm-generic/vmlinux.lds.h | 6 ++++-
lib/Kconfig.debug | 42 +++++++++++++++++++++++++------
scripts/test_dwarf5_support.sh | 8 ++++++
4 files changed, 57 insertions(+), 12 deletions(-)
create mode 100755 scripts/test_dwarf5_support.sh

--
2.30.0.284.gd98b1dd5eaa7-goog

[Nick Desaulniers]

From: Masahiro Yamada <masa...@kernel.org>

The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.

You can see it at https://godbolt.org/z/6ed1oW

For gcc 4.5.3 pane, line 37: .value 0x4
For clang 10.0.1 pane, line 117: .short 4

Given Documentation/process/changes.rst stating GCC 4.9 is the minimal
version, this cc-option is unneeded.

Note
----

CONFIG_DEBUG_INFO_DWARF4 controls the DWARF version only for C files.

As you can see in the top Makefile, -gdwarf-4 is only passed to CFLAGS.

ifdef CONFIG_DEBUG_INFO_DWARF4
DEBUG_CFLAGS += -gdwarf-4
endif

This flag is used when compiling *.c files.

On the other hand, the assembler is always given -gdwarf-2.

KBUILD_AFLAGS += -Wa,-gdwarf-2

Hence, the debug info that comes from *.S files is always DWARF v2.
This is simply because GAS supported only -gdwarf-2 for a long time.

Recently, GAS gained the support for --dwarf-[3|4|5] options. [1]
And, also we have Clang integrated assembler. So, the debug info
for *.S files might be improved if we want.

In my understanding, the current code is intentional, not a bug.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31bf18645d98b4d3d7357353be840e320649a67d

Reviewed-by: Nick Desaulniers <ndesau...@google.com>
Reviewed-by: Nathan Chancellor <natecha...@gmail.com>
Signed-off-by: Masahiro Yamada <masa...@kernel.org>

---
lib/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 78361f0abe3a..dd7d8d35b2a5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug

@@ -258,7 +258,6 @@ config DEBUG_INFO_SPLIT

config DEBUG_INFO_DWARF4
bool "Generate dwarf4 debuginfo"
- depends on $(cc-option,-gdwarf-4)
help

Generate dwarf4 debug info. This requires recent versions

of gcc and gdb. It makes the debug information larger.

--
2.30.0.284.gd98b1dd5eaa7-goog

[Nick Desaulniers]

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.

Suggested-by: Arvind Sankar <nive...@alum.mit.edu>

Suggested-by: Fangrui Song <mas...@google.com>
Suggested-by: Masahiro Yamada <masa...@kernel.org>
Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 13 ++++++-------
lib/Kconfig.debug | 21 ++++++++++++++++-----
2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
index d49c3f39ceb4..4eb3bf7ee974 100644
--- a/Makefile
+++ b/Makefile
@@ -826,13 +826,12 @@ else

DEBUG_CFLAGS += -g
endif

-ifneq ($(LLVM_IAS),1)
-KBUILD_AFLAGS += -Wa,-gdwarf-2

-endif

-
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS += -gdwarf-4

-endif

+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)

+# Binutils 2.35+ required for -gdwarf-4+ support.
+dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))

+KBUILD_AFLAGS += $(dwarf-aflag)

ifdef CONFIG_DEBUG_INFO_REDUCED
DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index dd7d8d35b2a5..e80770fac4f0 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug

[Nick Desaulniers]

DWARF v5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head -n 4 | grep version
or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2

515M vmlinux.gcc10.2.dwarf5.compressed
599M vmlinux.gcc10.2.dwarf4.compressed
624M vmlinux.gcc10.2.dwarf2.compressed
630M vmlinux.gcc10.2.dwarf5
765M vmlinux.gcc10.2.dwarf4
809M vmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
option that enabled some small DWARF subset (initially only a few
DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
after DWARF 5 has been finalized) started emitting DWARF5 section
headers and got most of the DWARF5 changes in...

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

GNU `as` only recently gained support for specifying -gdwarf-5, so when
compiling with Clang but without Clang's integrated assembler
(LLVM_IAS=1 is not set), explicitly add -Wa,-gdwarf-5 to DEBUG_CFLAGS.

Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info. Thanks to Sedat for
the report.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Reported-by: Sedat Dilek <sedat...@gmail.com>
Suggested-by: Arvind Sankar <nive...@alum.mit.edu>
Suggested-by: Caroline Tice <cmt...@google.com>
Suggested-by: Fangrui Song <mas...@google.com>

Suggested-by: Jakub Jelinek <ja...@redhat.com>
Suggested-by: Masahiro Yamada <masa...@kernel.org>

Suggested-by: Nathan Chancellor <natecha...@gmail.com>

Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---

Makefile | 6 ++++++
include/asm-generic/vmlinux.lds.h | 6 +++++-
lib/Kconfig.debug | 18 ++++++++++++++++++
scripts/test_dwarf5_support.sh | 8 ++++++++
4 files changed, 37 insertions(+), 1 deletion(-)
create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index 4eb3bf7ee974..1dcea03861ef 100644
--- a/Makefile
+++ b/Makefile
@@ -828,10 +828,16 @@ endif

dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)

# Binutils 2.35+ required for -gdwarf-4+ support.

dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
KBUILD_AFLAGS += $(dwarf-aflag)
+ifdef CONFIG_CC_IS_CLANG
+ifneq ($(LLVM_IAS),1)
+DEBUG_CFLAGS += $(dwarf-aflag)
+endif
+endif

ifdef CONFIG_DEBUG_INFO_REDUCED
DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 49944f00d2b3..37dc4110875e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -843,7 +843,11 @@
.debug_types 0 : { *(.debug_types) } \
/* DWARF 5 */ \
.debug_macro 0 : { *(.debug_macro) } \
- .debug_addr 0 : { *(.debug_addr) }
+ .debug_addr 0 : { *(.debug_addr) } \
+ .debug_line_str 0 : { *(.debug_line_str) } \
+ .debug_loclists 0 : { *(.debug_loclists) } \
+ .debug_rnglists 0 : { *(.debug_rnglists) } \
+ .debug_str_offsets 0 : { *(.debug_str_offsets) }

/* Stabs debugging sections. */
#define STABS_DEBUG \

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e80770fac4f0..658f32ec0c05 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -273,6 +273,24 @@ config DEBUG_INFO_DWARF4

It makes the debug information larger, but it significantly

improves the success of resolving variables in gdb on optimized code.

+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF Version 5 debuginfo"
+ depends on GCC_VERSION >= 50000 || CC_IS_CLANG
+ depends on CC_IS_GCC || $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
+ depends on !DEBUG_INFO_BTF
+ help

+ Generate DWARF v5 debug info. Requires binutils 2.35, gcc 5.0+ (gcc
+ 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
+ draft features until 7.0), and gdb 8.0+.
+
+ Changes to the structure of debug info in Version 5 allow for around
+ 15-18% savings in resulting image and debug info section sizes as
+ compared to DWARF Version 4. DWARF Version 5 standardizes previous
+ extensions such as accelerators for symbol indexing and the format
+ for fission (.dwo/.dwp) files. Users may not want to select this
+ config if they rely on tooling that has not yet been updated to
+ support DWARF Version 5.
+

endchoice # "DWARF version"

config DEBUG_INFO_BTF

diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
new file mode 100755

index 000000000000..1a00484d0b2e
--- /dev/null
+++ b/scripts/test_dwarf5_support.sh
@@ -0,0 +1,8 @@

+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
+# in binutils < 2.35.
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
+# https://sourceware.org/bugzilla/show_bug.cgi?id=25614

[Sedat Dilek]

Here you use "DWARF version" so keep this for v2 and v4.

> + help
> + Which version of DWARF debug info to emit.
> +
> +config DEBUG_INFO_DWARF2
> + bool "Generate DWARF Version 2 debuginfo"

s/DWARF Version/DWARF version

> + help
> + Generate DWARF v2 debug info.
> +
> config DEBUG_INFO_DWARF4
> - bool "Generate dwarf4 debuginfo"
> + bool "Generate DWARF Version 4 debuginfo"

Same here: s/DWARF Version/DWARF version

- Sedat -

[Sedat Dilek]

On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
<ndesau...@google.com> wrote:
>

Better keep GCC depends in one line:

+ depends on CC_IS_GCC && GCC_VERSION >= 50000 || CC_IS_CLANG
+ depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh
$(CC) $(CLANG_FLAGS))

As said in the other patch:

Use consistently: s/DWARF Version/DWARF version/g

- Sedat -

[Sedat Dilek]

On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
<ndesau...@google.com> wrote:
>

Subject misses a "kbuild:" label like in all other patches.
You have:

"Remove $(cc-option,-gdwarf-4) dependency from CONFIG_DEBUG_INFO_DWARF4"

- Sedat -

[Nick Desaulniers]

It's intentional, if a bit obtuse:
We don't want to check the assembler support for -Wa,-gdwarf-5 via
compiler driver when CC=gcc; instead, we'll rely on how GCC was
configured as per Arvind.

>
> As said in the other patch:
>
> Use consistently: s/DWARF Version/DWARF version/g

Ah right, and I forget your point about kbuild/Kbuild. Will wait for
more feedback then send a v6 next week. Thanks as always for the
feedback.

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

Ack, I wonder how that happened? Ah well, will fix in v6; thanks for
the feedback.

>
> - Sedat -
>
> > ---
> > lib/Kconfig.debug | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 78361f0abe3a..dd7d8d35b2a5 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -258,7 +258,6 @@ config DEBUG_INFO_SPLIT
> >
> > config DEBUG_INFO_DWARF4
> > bool "Generate dwarf4 debuginfo"
> > - depends on $(cc-option,-gdwarf-4)
> > help
> > Generate dwarf4 debug info. This requires recent versions
> > of gcc and gdb. It makes the debug information larger.
> > --
> > 2.30.0.284.gd98b1dd5eaa7-goog
> >

--
Thanks,
~Nick Desaulniers

[Sedat Dilek]

On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
<ndesau...@google.com> wrote:
>

En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
CONFIG_DEBUG_INFO_DWARF4.
So might be good to add a "depends on !DEBUG_INFO_BTF" in this combination.

I had some other small nits commented in the single patches.

As requested in your previous patch-series, feel free to add my:

Tested-by: Sedat Dilek <sedat...@gmail.com>

- Sedat -

[Sedat Dilek]

On Fri, Jan 15, 2021 at 10:49 PM Nick Desaulniers

Hmm, OK.
I have not tested my diff in diverse setup/combination of compiler and
"bin"utils.
So, I did not want to have a different behaviour.
Can you comment on this intentional setting in v6?

Thanks.

- Sedat -