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