diff mbox series

Kbuild: implement support for DWARF5

Message ID 20201022012106.1875129-1-ndesaulniers@google.com (mailing list archive)
State New, archived
Headers show
Series Kbuild: implement support for DWARF5 | expand

Commit Message

Nick Desaulniers Oct. 22, 2020, 1:21 a.m. UTC
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 <ndesaulniers@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

Comments

Fangrui Song Oct. 22, 2020, 1:44 a.m. UTC | #1
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)

>$ 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 <ndesaulniers@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) }

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.

> 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
>
>-- 
>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-linux+unsubscribe@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 Oct. 28, 2020, 6:18 p.m. UTC | #2
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?

On Wed, Oct 21, 2020 at 6:21 PM Nick Desaulniers
<ndesaulniers@google.com> 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:
> $ 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 <ndesaulniers@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
>
Masahiro Yamada Nov. 2, 2020, 2:20 a.m. UTC | #3
On Thu, Oct 22, 2020 at 10:21 AM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> 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:
> $ 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 <ndesaulniers@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

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)






> +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"

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.


> +       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 -



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-linux+unsubscribe@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 Nov. 2, 2020, 8:18 a.m. UTC | #4
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 Nov. 3, 2020, 10:13 p.m. UTC | #5
On Sun, Nov 1, 2020 at 6:21 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, Oct 22, 2020 at 10:21 AM 'Nick Desaulniers' via Clang Built
> Linux <clang-built-linux@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.

>
>
> 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
Nick Desaulniers Nov. 3, 2020, 10:21 p.m. UTC | #6
On Mon, Nov 2, 2020 at 12:18 AM Jakub Jelinek <jakub@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.
Nick Desaulniers Nov. 3, 2020, 10:27 p.m. UTC | #7
On Wed, Oct 21, 2020 at 6:44 PM Fangrui Song <maskray@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.
Arvind Sankar Nov. 4, 2020, midnight UTC | #8
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 Nov. 4, 2020, 12:05 a.m. UTC | #9
On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <nivedita@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.
Arvind Sankar Nov. 4, 2020, 12:17 a.m. UTC | #10
On Tue, Nov 03, 2020 at 04:05:36PM -0800, Nick Desaulniers wrote:
> On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <nivedita@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.
Jakub Jelinek Nov. 4, 2020, 12:19 p.m. UTC | #11
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
Nick Desaulniers Dec. 3, 2020, 10:56 p.m. UTC | #12
On Tue, Nov 3, 2020 at 4:17 PM Arvind Sankar <nivedita@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 <nivedita@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.
Nick Desaulniers Dec. 4, 2020, 12:17 a.m. UTC | #13
On Thu, Dec 3, 2020 at 2:56 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Tue, Nov 3, 2020 at 4:17 PM Arvind Sankar <nivedita@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 <nivedita@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.

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.
diff mbox series

Patch

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 -