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 <[email protected]>
---
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
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 <[email protected]>
>---
>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 [email protected].
>To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201022012106.1875129-1-ndesaulniers%40google.com.
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
<[email protected]> 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 <[email protected]>
> ---
> 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
>
--
Thanks,
~Nick Desaulniers
On Thu, Oct 22, 2020 at 10:21 AM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> 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 <[email protected]>
> ---
> 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 [email protected].
> 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
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
On Sun, Nov 1, 2020 at 6:21 PM Masahiro Yamada <[email protected]> wrote:
>
> On Thu, Oct 22, 2020 at 10:21 AM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> 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
--
Thanks,
~Nick Desaulniers
On Mon, Nov 2, 2020 at 12:18 AM Jakub Jelinek <[email protected]> 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
On Wed, Oct 21, 2020 at 6:44 PM Fangrui Song <[email protected]> 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
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?
On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <[email protected]> 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
On Tue, Nov 03, 2020 at 04:05:36PM -0800, Nick Desaulniers wrote:
> On Tue, Nov 3, 2020 at 4:00 PM Arvind Sankar <[email protected]> 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.
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/[email protected]/
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
From: Fangrui Song <[email protected]>
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 <[email protected]>
Signed-off-by: Fangrui Song <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Cc: <[email protected]>
---
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
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: <[email protected]>
Link: https://github.com/ClangBuiltLinux/linux/issues/716
Reported-by: Nathan Chancellor <[email protected]>
Suggested-by: Dmitry Golovin <[email protected]>
Suggested-by: Sedat Dilek <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
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
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 <[email protected]>
Suggested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
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
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 <[email protected]>
Suggested-by: Jakub Jelinek <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
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
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
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 <[email protected]>
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/[email protected]
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: <[email protected]>
> Link: https://github.com/ClangBuiltLinux/linux/issues/716
> Reported-by: Nathan Chancellor <[email protected]>
> Suggested-by: Dmitry Golovin <[email protected]>
If you happen to respin, Dmitry deserves a Reported-by tag too :)
> Suggested-by: Sedat Dilek <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
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 <[email protected]>
> ---
> 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)
> KBUILD_AFLAGS += -Wa,-gdwarf-2
> +endif
>
> ifdef CONFIG_DEBUG_INFO_DWARF4
> DEBUG_CFLAGS += -gdwarf-4
> --
> 2.29.1.341.ge80a0c044ae-goog
>
On 2020-11-04, Nathan Chancellor 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?
>
>> 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: <[email protected]>
>> Link: https://github.com/ClangBuiltLinux/linux/issues/716
>> Reported-by: Nathan Chancellor <[email protected]>
>> Suggested-by: Dmitry Golovin <[email protected]>
>
>If you happen to respin, Dmitry deserves a Reported-by tag too :)
>
>> Suggested-by: Sedat Dilek <[email protected]>
>> Signed-off-by: Nick Desaulniers <[email protected]>
>
>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 <[email protected]>
>
>> ---
>> 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)
>
>> KBUILD_AFLAGS += -Wa,-gdwarf-2
>> +endif
>>
>> ifdef CONFIG_DEBUG_INFO_DWARF4
>> DEBUG_CFLAGS += -gdwarf-4
>> --
>> 2.29.1.341.ge80a0c044ae-goog
>>
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 <[email protected]>
On Wed, Nov 4, 2020 at 10:58 PM Nathan Chancellor
<[email protected]> 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: <[email protected]>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/716
> > Reported-by: Nathan Chancellor <[email protected]>
> > Suggested-by: Dmitry Golovin <[email protected]>
>
> If you happen to respin, Dmitry deserves a Reported-by tag too :)
Sure.
>
> > Suggested-by: Sedat Dilek <[email protected]>
> > Signed-off-by: Nick Desaulniers <[email protected]>
>
> 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 <[email protected]>
>
> > ---
> > 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
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: <[email protected]>
Link: https://github.com/ClangBuiltLinux/linux/issues/716
Reported-by: Dmitry Golovin <[email protected]>
Reported-by: Nathan Chancellor <[email protected]>
Suggested-by: Dmitry Golovin <[email protected]>
Suggested-by: Nathan Chancellor <[email protected]>
Suggested-by: Sedat Dilek <[email protected]>
Reviewed-by: Fangrui Song <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
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
Hi Masahiro, have you had time to review v3 of this patch?
On Mon, Nov 9, 2020 at 10:35 AM Nick Desaulniers
<[email protected]> 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 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: <[email protected]>
> Link: https://github.com/ClangBuiltLinux/linux/issues/716
> Reported-by: Dmitry Golovin <[email protected]>
> Reported-by: Nathan Chancellor <[email protected]>
> Suggested-by: Dmitry Golovin <[email protected]>
> Suggested-by: Nathan Chancellor <[email protected]>
> Suggested-by: Sedat Dilek <[email protected]>
> Reviewed-by: Fangrui Song <[email protected]>
> Reviewed-by: Nathan Chancellor <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
> ---
> 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
>
--
Thanks,
~Nick Desaulniers
Hi Masahiro,
I would appreciate any feedback you have on this patch.
On Fri, Nov 20, 2020 at 3:58 PM Jian Cai <[email protected]> wrote:
>
> 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 <[email protected]> # Compile-tested on mainline (with defconfig) and boot-tested on ChromeOS (with olddefconfig).
>
>
> On Mon, Nov 16, 2020 at 3:41 PM 'Nick Desaulniers' via Clang Built Linux <[email protected]> wrote:
>>
>> Hi Masahiro, have you had time to review v3 of this patch?
>>
>> On Mon, Nov 9, 2020 at 10:35 AM Nick Desaulniers
>> <[email protected]> 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 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: <[email protected]>
>> > Link: https://github.com/ClangBuiltLinux/linux/issues/716
>> > Reported-by: Dmitry Golovin <[email protected]>
>> > Reported-by: Nathan Chancellor <[email protected]>
>> > Suggested-by: Dmitry Golovin <[email protected]>
>> > Suggested-by: Nathan Chancellor <[email protected]>
>> > Suggested-by: Sedat Dilek <[email protected]>
>> > Reviewed-by: Fangrui Song <[email protected]>
>> > Reviewed-by: Nathan Chancellor <[email protected]>
>> > Signed-off-by: Nick Desaulniers <[email protected]>
>> > ---
>> > 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
>> >
>>
>>
>> --
>> 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 [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdnxAr7UdjUiuttj%3Dbz1_voK1qUvpOvSY35qOZ60%2BE8LBA%40mail.gmail.com.
--
Thanks,
~Nick Desaulniers
On Tue, Nov 03, 2020 at 04:53:42PM -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 <[email protected]>
> Suggested-by: Masahiro Yamada <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
> ---
> 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
>
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?
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
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 :-)
>
>
> Segher
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.
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.
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
On Tue, Nov 24, 2020 at 3:42 AM Nick Desaulniers
<[email protected]> wrote:
>
> Hi Masahiro,
> I would appreciate any feedback you have on this patch.
>
Applied to linux-kbuild. Thanks.
> On Fri, Nov 20, 2020 at 3:58 PM Jian Cai <[email protected]> wrote:
> >
> > 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 <[email protected]> # Compile-tested on mainline (with defconfig) and boot-tested on ChromeOS (with olddefconfig).
> >
> >
> > On Mon, Nov 16, 2020 at 3:41 PM 'Nick Desaulniers' via Clang Built Linux <[email protected]> wrote:
> >>
> >> Hi Masahiro, have you had time to review v3 of this patch?
> >>
> >> On Mon, Nov 9, 2020 at 10:35 AM Nick Desaulniers
> >> <[email protected]> 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 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: <[email protected]>
> >> > Link: https://github.com/ClangBuiltLinux/linux/issues/716
> >> > Reported-by: Dmitry Golovin <[email protected]>
> >> > Reported-by: Nathan Chancellor <[email protected]>
> >> > Suggested-by: Dmitry Golovin <[email protected]>
> >> > Suggested-by: Nathan Chancellor <[email protected]>
> >> > Suggested-by: Sedat Dilek <[email protected]>
> >> > Reviewed-by: Fangrui Song <[email protected]>
> >> > Reviewed-by: Nathan Chancellor <[email protected]>
> >> > Signed-off-by: Nick Desaulniers <[email protected]>
> >> > ---
> >> > 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
> >> >
> >>
> >>
> >> --
> >> 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 [email protected].
> >> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdnxAr7UdjUiuttj%3Dbz1_voK1qUvpOvSY35qOZ60%2BE8LBA%40mail.gmail.com.
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Best Regards
Masahiro Yamada
On Wed, Nov 4, 2020 at 9:53 AM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> 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 <[email protected]>
> Suggested-by: Masahiro Yamada <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
> ---
> 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)
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?
> +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
>
> --
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201104005343.4192504-4-ndesaulniers%40google.com.
--
Best Regards
Masahiro Yamada
On Mon, Nov 30, 2020 at 10:05 AM Masahiro Yamada <[email protected]> wrote:
>
> On Wed, Nov 4, 2020 at 9:53 AM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> 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 <[email protected]>
> > Suggested-by: Masahiro Yamada <[email protected]>
> > Signed-off-by: Nick Desaulniers <[email protected]>
> > ---
> > 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)
>
> 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?
>
>
>
> > +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
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).
--
宋方睿
On Mon, Nov 30, 2020 at 10:05 AM Masahiro Yamada <[email protected]> wrote:
>
> On Wed, Nov 4, 2020 at 9:53 AM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> 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 <[email protected]>
> > Suggested-by: Masahiro Yamada <[email protected]>
> > Signed-off-by: Nick Desaulniers <[email protected]>
> > ---
> > 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)
>
> 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?
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
On Wed, Nov 4, 2020 at 9:54 AM Nick Desaulniers <[email protected]> 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.
>
> 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 <[email protected]>
> Suggested-by: Jakub Jelinek <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
> ---
> 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"
The choice menu looks like follows:
(X) Generate DWARF v2 debuginfo
( ) Generate dwarf4 debuginfo
( ) Generate DWARF5 debuginfo
Upper / Lower case inconsistency.
--
Best Regards
Masahiro Yamada
On Tue, Dec 1, 2020 at 5:27 AM 'Fāng-ruì Sòng' via Clang Built Linux
<[email protected]> wrote:
>
> On Mon, Nov 30, 2020 at 10:05 AM Masahiro Yamada <[email protected]> wrote:
> >
> > On Wed, Nov 4, 2020 at 9:53 AM 'Nick Desaulniers' via Clang Built
> > Linux <[email protected]> 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 <[email protected]>
> > > Suggested-by: Masahiro Yamada <[email protected]>
> > > Signed-off-by: Nick Desaulniers <[email protected]>
> > > ---
> > > 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)
> >
> > 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?
> >
> >
> >
> > > +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
>
>
> 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.
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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAFP8O3Ki9HoqcV450fn29fBOWAbmuGAdB6USLz8pGsW4Vzf7sg%40mail.gmail.com.
--
Best Regards
Masahiro Yamada
On Tue, Dec 1, 2020 at 5:45 AM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> wrote:
>
> On Mon, Nov 30, 2020 at 10:05 AM Masahiro Yamada <[email protected]> wrote:
> >
> > On Wed, Nov 4, 2020 at 9:53 AM 'Nick Desaulniers' via Clang Built
> > Linux <[email protected]> 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 <[email protected]>
> > > Suggested-by: Masahiro Yamada <[email protected]>
> > > Signed-off-by: Nick Desaulniers <[email protected]>
> > > ---
> > > 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)
> >
> > 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?
>
> 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
>
> --
> 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 [email protected].
> 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
--
Best Regards
Masahiro Yamada
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
On 2020-12-01, Segher Boessenkool wrote:
>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.
>
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).
On Tue, Nov 3, 2020 at 4:17 PM Arvind Sankar <[email protected]> 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 <[email protected]> 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
On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <[email protected]> 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
On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <[email protected]> wrote:
>
> On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <[email protected]> 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
On Thu, Dec 3, 2020 at 2:56 PM Nick Desaulniers <[email protected]> wrote:
>
> On Tue, Nov 3, 2020 at 4:17 PM Arvind Sankar <[email protected]> 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 <[email protected]> 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.
--
Thanks,
~Nick Desaulniers
On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <[email protected]> wrote:
> >
> > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <[email protected]> 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.
On Fri, Dec 4, 2020 at 9:06 AM Arvind Sankar <[email protected]> wrote:
>
> On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> > On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <[email protected]> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <[email protected]> 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.
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
On Thu, Dec 10, 2020 at 03:18:45PM -0800, Nick Desaulniers wrote:
> On Fri, Dec 4, 2020 at 9:06 AM Arvind Sankar <[email protected]> wrote:
> >
> > 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.
>
> 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?
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.