On Tue, Feb 1, 2022 at 3:45 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> I am in the process if writing a tool that can add .debug_names to a file
> that contains DWARF but doesn’t have an accelerator table that is adequate
> for debuggers to use. I was trying to see some example implementations of
> the .debug_names section to see exactly what I should emit from this tool.
>
> I have a question on the following section from the DWARF 5
> specification: 6.1.1.4.7 Abbreviations Table. It contains "Table 6.1: Index
> attribute encodings” which shows the available attributes for the
> abbreviations that can be used for each index entry:
>
> DW_IDX_compile_unit. // Index of CU
> DW_IDX_type_unit // Index of TU
> DW_IDX_die_offset // Offset of DIE within CU or TU
> DW_IDX_parent // Index of name table entry for parent
> DW_IDX_type_hash // Hash of type declaration
>
>
> My main question is what are the best practices for how producers should
> emit an entry for a specific DIE in this lookup table. One option is to
> specify both a CU index and a relative DIE offset:
>
> DW_IDX_compile_unit + DW_FORM_dataX form
> DW_IDX_die_offset + DW_FORM_ref4
>
> “DW_FORM_ref4” is known to be a CU relative offset.
>
> Or we can simply emit a single attribute for the die_offset using an
> absolute DIE offset reference?
>
> DW_IDX_die_offset + DW_FORM_ref_addr
>
> There isn’t much written up in the DWARF spec about these attributes
> except that it seems to imply that DW_IDX_die_offset must also have a CU or
> TU since the comment says "Offset of DIE within CU or TU”
>
> I was looking at the output of dsymutil, a smart DWARF linker maintained
> by Apple, and it can emit .debug_names with an option, but it emits
> the following abbreviation, as seen by using “llvm-dwarfdump --debug-names”:
>
> Abbreviation 0x16 {
> Tag: DW_TAG_typedef
> DW_IDX_die_offset: DW_FORM_ref4
> }
>
> And the in the Entry for each type, dsymutil only emits a DIE offset as
> a DW_FORM_ref4, which seems to imply it is an absolute offset:
>
> Bucket 0 [
> Name 1 {
> Hash: 0x4D51C8E0
> String: 0x000010c4 "pthread_t"
> Entry @ 0x5a7 {
> Abbrev: 0x16
> Tag: DW_TAG_typedef
> DW_IDX_die_offset: 0x00002162
> }
> }
> Name 2 {
> Hash: 0x8FEC1B20
> String: 0x00000323 "long int"
> Entry @ 0x5ad {
> Abbrev: 0x24
> Tag: DW_TAG_base_type
> DW_IDX_die_offset: 0x00000920
> }
> }
> ]
>
>
> Should dsymutil be emitting both a CU index and a CU relative offset, or
> should it just switch over to using a DW_FORM_ref_addr as the encoding for
> the DIE?
>
> Do any current compilers support emitting .debug_names when “-gdwarf-5” is
> produced?
>
Clang does (if you pass -gpubnames in addition to -gdwarf-5). Looks like it
only uses DW_FORM_ref4 as though they were absolute (not unit-relative)
offsets. Looks like @Pavel Labath <pa...@labath.sk> added this DWARFv5
.debug_names support in https://reviews.llvm.org/D43286
Ah, looks like the implementation only adds IDX_compile_unit if there's
more than one unit being produced:
https://github.com/llvm/llvm-project/blob/d7dd7ad827a0a78314f3c9b55f4778a6059840f3/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp#L410
Ah, this is consistent with DWARFv5, page 141 (6.1.1.2 Structure of the
Name Index):
"Compilation Unit (CU), a reference to an entry in the list of CUs. In a
per-CU index, index entries without this attribute implicitly refer to the
single CU."
So the ref4 is CU relative, even though there's no IDX_compile_unit
attribute on these entries - because there's only one CU in the table, so
there's an implicit value of IDX_compile_unit == 0.
> Any clarification or pointers to other producers would be appreciated!
>
> Greg Clayton
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
