DWARF5 and .gdb_index/.debug_names

DWARF5 and .gdb_index/.debug_names

[Mark Wielaard]

Hi,

Last week we had a DWARF BoF at the virtual GNU tools cauldron.
Notes have been posted to the gcc wiki:
https://gcc.gnu.org/wiki/LPC2020NotesDWARF

I would like to try to make DWARF5 the default for GCC11 and have been
trying to fix any issues I could find. Testing gdb went pretty well.
There is one issue that I originally filed against gdb:
https://sourceware.org/bugzilla/show_bug.cgi?id=26525
But that is most likely a bug in gcc. Jakub has a patch that fixes the
issue for gcc, but there is some debate whether that is the correct
approach or not:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552535.html

Note that I haven't really looked for issues in languages other than C
or C++, so someone might want to double check whether other languages
supported by gcc are also ready to switch to DWARF5 by default.

During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
is incomplete/wrong. I was wondering whether there was a good
description of the issue and/or a bug report for it. When using the
contrib/gdb-add-index.sh it does add a .gdb_index for objects
containing DWARF5 and the results seem correct, gdb also seems to be
able to use it. When adding -dwarf-5 it seems to output a .debug_names
section which can be read by binutils readelf (elfutils doesn't yet
support .debug_names). I couldn't immediately see in what way it was
wrong/incomplete.

dwz does support .gdb_index rewriting, but doesn't know about
.debug_names yet. So could we as a first step, when switching the
DWARF5 keep using .gdb_index? At least till any issues with gdb
.debug_names are resolved and dwz supports it?

Thanks,

Mark

Re: DWARF5 and .gdb_index/.debug_names

[Tom de Vries]

On 8/30/20 7:18 PM, Mark Wielaard wrote:
> Hi,
> 
> Last week we had a DWARF BoF at the virtual GNU tools cauldron.
> Notes have been posted to the gcc wiki:
> https://gcc.gnu.org/wiki/LPC2020NotesDWARF
> 
> I would like to try to make DWARF5 the default for GCC11 and have been
> trying to fix any issues I could find. Testing gdb went pretty well.
> There is one issue that I originally filed against gdb:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26525
> But that is most likely a bug in gcc. Jakub has a patch that fixes the
> issue for gcc, but there is some debate whether that is the correct
> approach or not:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552535.html
> 
> Note that I haven't really looked for issues in languages other than C
> or C++, so someone might want to double check whether other languages
> supported by gcc are also ready to switch to DWARF5 by default.
> 
> During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
> is incomplete/wrong. I was wondering whether there was a good
> description of the issue and/or a bug report for it. When using the
> contrib/gdb-add-index.sh it does add a .gdb_index for objects
> containing DWARF5 and the results seem correct, gdb also seems to be
> able to use it. When adding -dwarf-5 it seems to output a .debug_names
> section which can be read by binutils readelf (elfutils doesn't yet
> support .debug_names). I couldn't immediately see in what way it was
> wrong/incomplete.
> 

I filed a few issues related to .debug_names:
- https://sourceware.org/bugzilla/show_bug.cgi?id=25969
- https://sourceware.org/bugzilla/show_bug.cgi?id=25950
- https://sourceware.org/bugzilla/show_bug.cgi?id=25953

Thanks,
- Tom

> dwz does support .gdb_index rewriting, but doesn't know about
> .debug_names yet. So could we as a first step, when switching the
> DWARF5 keep using .gdb_index? At least till any issues with gdb
> .debug_names are resolved and dwz supports it?
> 
> Thanks,
> 
> Mark
> 

Re: DWARF5 and .gdb_index/.debug_names

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Sun, 30 Aug 2020 19:18:51 +0200, Mark Wielaard wrote:
> During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
> is incomplete/wrong. I was wondering whether there was a good
> description of the issue and/or a bug report for it. When using the
> contrib/gdb-add-index.sh it does add a .gdb_index for objects
> containing DWARF5 and the results seem correct, gdb also seems to be
> able to use it. When adding -dwarf-5 it seems to output a .debug_names
> section which can be read by binutils readelf (elfutils doesn't yet
> support .debug_names). I couldn't immediately see in what way it was
> wrong/incomplete.

.debug_names from GDB needs to produce also DW_IDX_die_offset to make it
consumable by debuggers with reasonable performance.

Then I see clang++ -gdwarf-5 -gpubnames produces C++ names mangled while GDB
produces them unmangled. I haven't found anything in DWARF-5 standard
suggesting either. Given mangled->unmangled mapping is possible but
unmangled->mangled is not (such as variants of ctors/dtors) I find the clang
way should be followed.


Jan

[-- Attachment #2: ns3.debug_names --]
[-- Type: text/plain, Size: 1818 bytes --]

ns3:	file format ELF64-x86-64

.debug_names contents:
Name Index @ 0x0 {
  Header {
    Length: 0xC4
    Version: 5
    Padding: 0x0
    CU count: 1
    Local TU count: 0
    Foreign TU count: 0
    Bucket count: 5
    Name count: 5
    Abbreviations table size: 0x19
    Augmentation: 'LLVM0700'
  }
  Compilation Unit offsets [
    CU[0]: 0x00000000
  ]
  Abbreviations [
    Abbreviation 0x34 {
      Tag: DW_TAG_variable
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x2 {
      Tag: DW_TAG_class_type
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x2e {
      Tag: DW_TAG_subprogram
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x24 {
      Tag: DW_TAG_base_type
      DW_IDX_die_offset: DW_FORM_ref4
    }
  ]
  Bucket 0 [
    EMPTY
  ]
  Bucket 1 [
    Name 1 {
      Hash: 0x7C9A7F6A
      String: 0x00000052 "main"
      Entry @ 0x99 {
        Abbrev: 0x2E
        Tag: DW_TAG_subprogram
        DW_IDX_die_offset: 0x00000041
      }
    }
  ]
  Bucket 2 [
    Name 2 {
      Hash: 0x2B608
      String: 0x00000030 "C"
      Entry @ 0xa2 {
        Abbrev: 0x2
        Tag: DW_TAG_class_type
        DW_IDX_die_offset: 0x0000002c
      }
    }
  ]
  Bucket 3 [
    Name 3 {
      Hash: 0x2B60E
      String: 0x00000043 "i"
      Entry @ 0xab {
        Abbrev: 0x34
        Tag: DW_TAG_variable
        DW_IDX_die_offset: 0x00000023
      }
    }
    Name 4 {
      Hash: 0xB888030
      String: 0x00000045 "int"
      Entry @ 0xb4 {
        Abbrev: 0x24
        Tag: DW_TAG_base_type
        DW_IDX_die_offset: 0x0000003d
      }
    }
    Name 5 {
      Hash: 0xDBA78B3F
      String: 0x00000049 "_ZN1C1iE"
      Entry @ 0xbd {
        Abbrev: 0x34
        Tag: DW_TAG_variable
        DW_IDX_die_offset: 0x00000023
      }
    }
  ]
  Bucket 4 [
    EMPTY
  ]
}

[-- Attachment #3: ns3g.debug_names --]
[-- Type: application/octet-stream, Size: 2120 bytes --]

[-- Attachment #4: ns3.C --]
[-- Type: text/plain, Size: 73 bytes --]

class C {
public:
static inline int i=42;
};
int main() { return C::i; }

Re: DWARF5 and .gdb_index/.debug_names

[David Blaikie]

On Mon, Aug 31, 2020 at 1:29 AM Jan Kratochvil via Gdb <gdb@sourceware.org>
wrote:

> On Sun, 30 Aug 2020 19:18:51 +0200, Mark Wielaard wrote:
> > During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
> > is incomplete/wrong. I was wondering whether there was a good
> > description of the issue and/or a bug report for it. When using the
> > contrib/gdb-add-index.sh it does add a .gdb_index for objects
> > containing DWARF5 and the results seem correct, gdb also seems to be
> > able to use it. When adding -dwarf-5 it seems to output a .debug_names
> > section which can be read by binutils readelf (elfutils doesn't yet
> > support .debug_names). I couldn't immediately see in what way it was
> > wrong/incomplete.
>
> .debug_names from GDB needs to produce also DW_IDX_die_offset to make it
> consumable by debuggers with reasonable performance.
>
> Then I see clang++ -gdwarf-5 -gpubnames produces C++ names mangled while
> GDB
> produces them unmangled. I haven't found anything in DWARF-5 standard
> suggesting either.


DWARFv5, Page 137 lists the things that must be in the debug_names table,
including:

"If a subprogram or inlined subroutine is included, and has a
DW_AT_linkage_name attribute, there will be an additional index entry for
the linkage name."

It's really important that all the producers ensure the names present are
the same/at least what is in the spec, otherwise we can easily erode trust
in the name table and consumers may end up having to ignore it to ensure
correctness.


> Given mangled->unmangled mapping is possible but
> unmangled->mangled is not (such as variants of ctors/dtors) I find the
> clang
> way should be followed.
>
>
> Jan
>

Re: DWARF5 and .gdb_index/.debug_names

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
Mark> is incomplete/wrong. I was wondering whether there was a good
Mark> description of the issue and/or a bug report for it.

It's been a while but last time I looked I thought gdb's process emitted
incorrect names.  I filed this bug, with analysis:

https://sourceware.org/bugzilla/show_bug.cgi?id=24820

gdb's reader probably also needs updating, since it relies on this same
incorrect reading of the standard.

Having gdb write the index is mildly bad anyway.  It should be in the
linker, and/or dwz or debuginfod.  Putting it in gdb back in the
.gdb_index days was a mistake.

Tom

Re: DWARF5 and .gdb_index/.debug_names

[David Blaikie]

On Tue, Sep 1, 2020 at 11:38 AM Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
>
> Mark> During the BoF Pedro mentioned that the GDB DWARF5 .debug_names
> support
> Mark> is incomplete/wrong. I was wondering whether there was a good
> Mark> description of the issue and/or a bug report for it.
>
> It's been a while but last time I looked I thought gdb's process emitted
> incorrect names.  I filed this bug, with analysis:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=24820
>
> gdb's reader probably also needs updating, since it relies on this same
> incorrect reading of the standard.
>
> Having gdb write the index is mildly bad anyway.  It should be in the
> linker, and/or dwz or debuginfod.  Putting it in gdb back in the
> .gdb_index days was a mistake.
>

FWIW, there are times where you might not want to add this at production
time - at least with lld, for instance, it takes significantly more
memory/linker time. So if you're building more often than you're debugging,
it might be nice to build without an index to speed up the build/test loop,
then only pay the index building cost when you end up wanting to debug
something.

- Dave

Re: DWARF5 and .gdb_index/.debug_names

[Pedro Alves]

On 8/30/20 6:18 PM, Mark Wielaard wrote:
> dwz does support .gdb_index rewriting, but doesn't know about
> .debug_names yet. So could we as a first step, when switching the
> DWARF5 keep using .gdb_index? At least till any issues with gdb
> .debug_names are resolved and dwz supports it?

I'm not aware of anything that would force use of DWARF5 to also
imply use of .debug_names, or that would prevent using .gdb_index.
AFAIK, we can treat them as orthogonal.  

Pedro Alves

Re: DWARF5 and .gdb_index/.debug_names

[Eric Christopher]

On Tue, Sep 1, 2020 at 3:17 PM Pedro Alves <pedro@palves.net> wrote:

> On 8/30/20 6:18 PM, Mark Wielaard wrote:
> > dwz does support .gdb_index rewriting, but doesn't know about
> > .debug_names yet. So could we as a first step, when switching the
> > DWARF5 keep using .gdb_index? At least till any issues with gdb
> > .debug_names are resolved and dwz supports it?
>
> I'm not aware of anything that would force use of DWARF5 to also
> imply use of .debug_names, or that would prevent using .gdb_index.
> AFAIK, we can treat them as orthogonal.
>
>
Exactly. :)

debug_names was an attempt to get a "this is one documented way to do it
that doesn't contain debugger internals" rather than anything endemic to
dwarf5.

-eric

Re: DWARF5 and .gdb_index/.debug_names

[Gaius Mulley]

Mark Wielaard <mark@klomp.org> writes:

> Hi,
>
> Last week we had a DWARF BoF at the virtual GNU tools cauldron.

an interesting talk - thank you!

> Note that I haven't really looked for issues in languages other than C
> or C++, so someone might want to double check whether other languages
> supported by gcc are also ready to switch to DWARF5 by default.

although gm2 is not in the gcc tree (yet) I'm very keen to use dwarf5.
Just the prospect of SET type debugging would have been enough, but to
get WITH statement scopes and MODULE scoping as well :-) - great!


regards,
Gaius