Re: DWARF5 and .gdb_index/.debug_names

Jan Kratochvil via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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
ns3.debug_names (text/plain, 1.8 KB)
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
  ]
}
ns3g.debug_names (application/octet-stream, 2 KB) - not displayed
ns3.C (text/plain, 73 B)
class C {
public:
static inline int i=42;
};
int main() { return C::i; }
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.