DWARF5 and .gdb_index/.debug_names

Jan Kratochvil jan.kratochvil@redhat.com
Mon Aug 31 08:28:26 GMT 2020


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
-------------- next part --------------
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
  ]
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns3g.debug_names
Type: application/octet-stream
Size: 2017 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb/attachments/20200831/20a3435a/attachment.obj>
-------------- next part --------------
class C {
public:
static inline int i=42;
};
int main() { return C::i; }


More information about the Gdb mailing list