Re: Default to DWARF5
Hi Paul, On Fri, Jan 29, 2021 at 02:04:02PM -0600, Paul A. Clarke wrote: > On Fri, Jan 29, 2021 at 12:22:41PM +0100, Mark Wielaard wrote: > > The infinite loop is because off isn't updated to noff before calling > > continue in the while loop. Moving the last line of the loop off = > > noff; to the start of the loop should fix that. > > I noticed that, too. I'll report that over on linux-perf-users. > (That code is about 10 years old, surprisingly.) Thanks. Note that newer elfutils libdw (since support for DWARF5 was added) provide dwarf_get_units which makes iterating over CUs slightly simpler because it gives you the CU and DIE directly instead of having to deal with offsets. > > Why the call to dwarf_offdie fails is unclear. Try printing the error > > using dwarf_errmsg (-1) when it returns NULL. > > The message is not terribly helpful, to me anyway: > invalid DWARF Yeah, sorry, that is because DWARF5 looks invalid to old versions. > > If you also print out > > off (in hex) and the filename the dbg was created from you can inspect > > the file using [eu-]readelf --debug-dump=info to see how the DIEs look > > at that offset. > > I'm not a DWARF/DIE expert at this point to know what to look for. > -- > Contents of the .debug_info section: > > Compilation Unit @ offset 0x0: >Length:0x24 (32-bit) >Version: 5 >Abbrev Offset: 0x0 >Pointer Size: 8 > <0>: Abbrev Number: 1 (DW_TAG_compile_unit) >DW_AT_stmt_list : 0x0 > <11> DW_AT_low_pc : 0x100089d4 > <19> DW_AT_high_pc : 68 > <1a> DW_AT_name: (indirect string, offset: 0x0): start.S > <1e> DW_AT_comp_dir: (indirect string, offset: 0x8): > /path/to/AT.../sources/glibc/csu > <22> DW_AT_producer: (indirect string, offset: 0x5c): GNU AS 2.36.50 > <26> DW_AT_language: 32769(MIPS assembler) > ... > > Is there an incompatibility introduced with DWARF5? Yes, the unit header was extended in DWARF5, so the offset given to the first DIE by the old code is invalid. > > BTW. Make sure you have elfutils libdw version 0.172 or newer when > > dealing with DWARF5. Latest elfutils release is 0.182. > > SLES15SP2 has an older version: > $ rpm -qi libdw1 > Name: libdw1 > Version : 0.168 > Release : 4.5.3 Yes, unfortunately 0.168 is too old. It was released in 2016 before the DWARF 5 specification (which is from 2017). Cheers, Mark
Re: Default to DWARF5
On Fri, Jan 29, 2021 at 12:22:41PM +0100, Mark Wielaard wrote: > On Thu, Jan 28, 2021 at 08:25:20PM -0600, Paul A. Clarke wrote: > > The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a > > failure in the test suite for the IBM Advance Toolchain. The test in > > question uses "perf probe" to set a tracepoint at "main" in a newly built > > (with GCC 11) binary of "/bin/ld". With the patch applied, the command > > enters an infinte loop, calling libdw1 functions but making no progress. > > > > The infinite loop can be found in the Linux kernel > > tools/perf/utils/probe-finder.c: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/probe-finder.c?h=v5.11-rc5#n1190 > > > > > > The infinite loop is because off isn't updated to noff before calling > continue in the while loop. Moving the last line of the loop off = > noff; to the start of the loop should fix that. I noticed that, too. I'll report that over on linux-perf-users. (That code is about 10 years old, surprisingly.) > Why the call to dwarf_offdie fails is unclear. Try printing the error > using dwarf_errmsg (-1) when it returns NULL. The message is not terribly helpful, to me anyway: invalid DWARF > If you also print out > off (in hex) and the filename the dbg was created from you can inspect > the file using [eu-]readelf --debug-dump=info to see how the DIEs look > at that offset. I'm not a DWARF/DIE expert at this point to know what to look for. -- Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length:0x24 (32-bit) Version: 5 Abbrev Offset: 0x0 Pointer Size: 8 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <11> DW_AT_low_pc : 0x100089d4 <19> DW_AT_high_pc : 68 <1a> DW_AT_name: (indirect string, offset: 0x0): start.S <1e> DW_AT_comp_dir: (indirect string, offset: 0x8): /path/to/AT.../sources/glibc/csu <22> DW_AT_producer: (indirect string, offset: 0x5c): GNU AS 2.36.50 <26> DW_AT_language: 32769(MIPS assembler) ... Is there an incompatibility introduced with DWARF5? > BTW. Make sure you have elfutils libdw version 0.172 or newer when > dealing with DWARF5. Latest elfutils release is 0.182. SLES15SP2 has an older version: $ rpm -qi libdw1 Name: libdw1 Version : 0.168 Release : 4.5.3 PC
Re: Default to DWARF5
Hi Paul, On Thu, Jan 28, 2021 at 08:25:20PM -0600, Paul A. Clarke wrote: > The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a > failure in the test suite for the IBM Advance Toolchain. The test in > question uses "perf probe" to set a tracepoint at "main" in a newly built > (with GCC 11) binary of "/bin/ld". With the patch applied, the command > enters an infinte loop, calling libdw1 functions but making no progress. > > The infinite loop can be found in the Linux kernel > tools/perf/utils/probe-finder.c: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/probe-finder.c?h=v5.11-rc5#n1190 > The infinite loop is because off isn't updated to noff before calling continue in the while loop. Moving the last line of the loop off = noff; to the start of the loop should fix that. Why the call to dwarf_offdie fails is unclear. Try printing the error using dwarf_errmsg (-1) when it returns NULL. If you also print out off (in hex) and the filename the dbg was created from you can inspect the file using [eu-]readelf --debug-dump=info to see how the DIEs look at that offset. BTW. Make sure you have elfutils libdw version 0.172 or newer when dealing with DWARF5. Latest elfutils release is 0.182. Cheers, Mark
Re: Default to DWARF5
The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a failure in the test suite for the IBM Advance Toolchain. The test in question uses "perf probe" to set a tracepoint at "main" in a newly built (with GCC 11) binary of "/bin/ld". With the patch applied, the command enters an infinte loop, calling libdw1 functions but making no progress. The infinite loop can be found in the Linux kernel tools/perf/utils/probe-finder.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/probe-finder.c?h=v5.11-rc5#n1190 Reverting this patch permits the command to succeed. PC
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
Hi, On Mon, 2020-08-24 at 19:38 +0200, Jakub Jelinek wrote: > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote: > > DWARF5 makes it possible to read loclists tables without consulting > > the debuginfo tree by introducing a table header. Adding location > > views > > breaks this (at least for binutils and elfutils). So don't enable > > variable-location-views by default if DWARF5 or higher is selected. > > This should be discussed with Alex, CCed. > I'd say elfutils/binutils should just show .debug_loclists > independent of > .debug_info if there are no loc views and use .debug_info otherwise. So it turned out that it was really bugs in elfutils and binutils. For elfutils it now tracks locviews in .debug_loclists just like it did for .debug_loc: https://sourceware.org/pipermail/elfutils-devel/2020q3/002900.html For binutils it actually tracked locviews correctly, but didn't handle DW_LLE_start_end and DW_LLE_start_length. Patch submitted: https://sourceware.org/pipermail/binutils/2020-September/113510.html For tools that access the location lists (and locviews) through the DIE attributes this never was an issue. Patch retracted. Cheers, Mark
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
Hello, Mark, On Aug 25, 2020, Mark Wielaard wrote: > On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote: >> it would seem to >> make more sense to adopt and promote the proposed extension, >> implemented in =incompat5 in GCC, but it would need some >> implementation work in consumers to at least ignore the extension. > Is that what is described in: > http://www.fsfla.org/~lxoliva/papers/sfn/dwarf6-sfn-lvu.txt > Does it match the proposal in: > http://www.dwarfstd.org/ShowIssue.php?issue=170427.1 Yes, the implementation of incompat5 is supposed to match the enhancement to DWARF proposed in this issue. > Should we try to introduce your extending loclists proposal: > http://www.dwarfstd.org/ShowIssue.php?issue=170427.2 If it makes sense to you, sure. I think it could be useful for loclist compression, besides adding extensibility to an unusually rigid part of DWARF specs. I'm not attached to this particular formulation, though, and I'm not aware of any implementations thereof. I only felt the need for extending loclists and found myself severely constrained. > The main issue is that there is no formal way of extending the > loclists. *nod* Thanks, -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
Hi Alex, On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote: > it would seem to > make more sense to adopt and promote the proposed extension, > implemented in =incompat5 in GCC, but it would need some > implementation work in consumers to at least ignore the extension. Is that what is described in: http://www.fsfla.org/~lxoliva/papers/sfn/dwarf6-sfn-lvu.txt Does it match the proposal in: http://www.dwarfstd.org/ShowIssue.php?issue=170427.1 Should we try to introduce your extending loclists proposal: http://www.dwarfstd.org/ShowIssue.php?issue=170427.2 The main issue is that there is no formal way of extending the loclists. Thanks, Mark
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
On Tue, Aug 25, 2020 at 6:05 AM Alexandre Oliva wrote: > > On Aug 24, 2020, Jakub Jelinek wrote: > > > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote: > >> DWARF5 makes it possible to read loclists tables without consulting > >> the debuginfo tree by introducing a table header. Adding location views > >> breaks this (at least for binutils and elfutils). So don't enable > >> variable-location-views by default if DWARF5 or higher is selected. > > > This should be discussed with Alex, CCed. > > I'd say elfutils/binutils should just show .debug_loclists independent of > > .debug_info if there are no loc views and use .debug_info otherwise. > > I've suggested before that it made sense to me to start emitting > locviews when there were concrete plans to implement support for them in > debug info consumers. > > Without such plans, it would make more sense to just disable them > altogether. > > Now, if there are any such plans, it is disabling them for the default > debug format that doesn't make much sense to me; it would seem to make > more sense to adopt and promote the proposed extension, implemented in > =incompat5 in GCC, but it would need some implementation work in > consumers to at least ignore the extension. > > > Red Hat has had me involved in these efforts for over a decade, but I'm > not aware of its plans any more, and I don't know of anyone else driving > the implementation of locviews in consumers, so, given the little I > know, this patch seems like a timid step in a reasonable direction: > outputting locviews is no use if there are no consumers for it, more so > when they actively disturb existing standard-compliant consumers. But then leaving it enabled by default but not with -gdwarf-5 looks odd and backward to me as well. If the consensus is there's no use then please disable them by default everywhere instead. Richard. > -- > Alexandre Oliva, happy hacker > https://FSFLA.org/blogs/lxo/ > Free Software Activist > GNU Toolchain Engineer
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
On Aug 24, 2020, Jakub Jelinek wrote: > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote: >> DWARF5 makes it possible to read loclists tables without consulting >> the debuginfo tree by introducing a table header. Adding location views >> breaks this (at least for binutils and elfutils). So don't enable >> variable-location-views by default if DWARF5 or higher is selected. > This should be discussed with Alex, CCed. > I'd say elfutils/binutils should just show .debug_loclists independent of > .debug_info if there are no loc views and use .debug_info otherwise. I've suggested before that it made sense to me to start emitting locviews when there were concrete plans to implement support for them in debug info consumers. Without such plans, it would make more sense to just disable them altogether. Now, if there are any such plans, it is disabling them for the default debug format that doesn't make much sense to me; it would seem to make more sense to adopt and promote the proposed extension, implemented in =incompat5 in GCC, but it would need some implementation work in consumers to at least ignore the extension. Red Hat has had me involved in these efforts for over a decade, but I'm not aware of its plans any more, and I don't know of anyone else driving the implementation of locviews in consumers, so, given the little I know, this patch seems like a timid step in a reasonable direction: outputting locviews is no use if there are no consumers for it, more so when they actively disturb existing standard-compliant consumers. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
Hi, On Mon, Aug 24, 2020 at 07:38:10PM +0200, Jakub Jelinek wrote: > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote: > > DWARF5 makes it possible to read loclists tables without consulting > > the debuginfo tree by introducing a table header. Adding location views > > breaks this (at least for binutils and elfutils). So don't enable > > variable-location-views by default if DWARF5 or higher is selected. > > This should be discussed with Alex, CCed. > I'd say elfutils/binutils should just show .debug_loclists independent of > .debug_info if there are no loc views and use .debug_info otherwise. Yes, sorry, should have CCed Alex. I do agree this is less than ideal. It was really just to make sure the elfutils testsuite was clean. But the issue is real. As is, when enabling DWARF5, it is impossible for consumers to parse the .debug_loclists independently. The only way to know whether (and where) the locviews are is by finding and then parsing the corresponding CU DIE tree. There is actually an alternative representation enabled by -gvariable-location-views=incompat5 that might help, but as the name implies it isn't standard DWARF5, and I believe neither elfutils nor binutils parses it. I am not sure what a good default is in case we enable -gdwarf-5. Cheers, Mark
Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> DWARF5 makes it possible to read loclists tables without consulting
> the debuginfo tree by introducing a table header. Adding location views
> breaks this (at least for binutils and elfutils). So don't enable
> variable-location-views by default if DWARF5 or higher is selected.
This should be discussed with Alex, CCed.
I'd say elfutils/binutils should just show .debug_loclists independent of
.debug_info if there are no loc views and use .debug_info otherwise.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 70dc1ab73a12..e5dddc236d7d 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -9301,9 +9301,9 @@ can be consumed by debug information consumers that are
> not aware of
> these augmentations, but they won't derive any benefit from them either.
>
> This is enabled by default when outputting DWARF 2 debug information at
> -the normal level, as long as there is assembler support,
> -@option{-fvar-tracking-assignments} is enabled and
> -@option{-gstrict-dwarf} is not. When assembler support is not
> +the normal level for DWARF versions lower than 5, as long as there
> +is assembler support, @option{-fvar-tracking-assignments} is enabled
> +and @option{-gstrict-dwarf} is not. When assembler support is not
> available, this may still be enabled, but it will force GCC to output
> internal line number tables, and if
> @option{-ginternal-reset-location-views} is not enabled, that will most
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 07457d08c3aa..34218c6b3349 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -1672,6 +1672,7 @@ process_options (void)
> && (write_symbols == DWARF2_DEBUG
> || write_symbols == VMS_AND_DWARF2_DEBUG)
> && !dwarf_strict
> +&& dwarf_version < 5
> && dwarf2out_as_loc_support
> && dwarf2out_as_locview_support);
> }
> --
> 2.18.4
Jakub
[PATCH 4/5] Default to DWARF5
---
gcc/common.opt | 2 +-
gcc/doc/invoke.texi | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 513125f0c00b..05e4e0638ecb 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3144,7 +3144,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
Generate debug information in default version of DWARF format.
gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
Generate debug information in DWARF v2 (or later) format.
ggdb
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e5dddc236d7d..511fcd25 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9042,13 +9042,14 @@ possible.
@opindex gdwarf
Produce debugging information in DWARF format (if that is supported).
The value of @var{version} may be either 2, 3, 4 or 5; the default version
-for most targets is 4. DWARF Version 5 is only experimental.
+for most targets is 5 (with the exception of vxworks and darwin which
+default to version 2).
Note that with DWARF Version 2, some ports require and always
use some non-conflicting DWARF 3 extensions in the unwind tables.
Version 4 may require GDB 7.0 and @option{-fvar-tracking-assignments}
-for maximum benefit.
+for maximum benefit. Version 5 requires GDB 8.0 or higher.
GCC no longer supports DWARF Version 1, which is substantially
different than Version 2 and later. For historical reasons, some
--
2.18.4
[PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.
DWARF5 makes it possible to read loclists tables without consulting
the debuginfo tree by introducing a table header. Adding location views
breaks this (at least for binutils and elfutils). So don't enable
variable-location-views by default if DWARF5 or higher is selected.
---
gcc/doc/invoke.texi | 6 +++---
gcc/toplev.c| 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 70dc1ab73a12..e5dddc236d7d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9301,9 +9301,9 @@ can be consumed by debug information consumers that are
not aware of
these augmentations, but they won't derive any benefit from them either.
This is enabled by default when outputting DWARF 2 debug information at
-the normal level, as long as there is assembler support,
-@option{-fvar-tracking-assignments} is enabled and
-@option{-gstrict-dwarf} is not. When assembler support is not
+the normal level for DWARF versions lower than 5, as long as there
+is assembler support, @option{-fvar-tracking-assignments} is enabled
+and @option{-gstrict-dwarf} is not. When assembler support is not
available, this may still be enabled, but it will force GCC to output
internal line number tables, and if
@option{-ginternal-reset-location-views} is not enabled, that will most
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 07457d08c3aa..34218c6b3349 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1672,6 +1672,7 @@ process_options (void)
&& (write_symbols == DWARF2_DEBUG
|| write_symbols == VMS_AND_DWARF2_DEBUG)
&& !dwarf_strict
+ && dwarf_version < 5
&& dwarf2out_as_loc_support
&& dwarf2out_as_locview_support);
}
--
2.18.4
