[Dwarf-Discuss] Producing .debug_names and questions about this lookup format

[David Blaikie]

On Tue, Feb 1, 2022 at 3:45 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss at 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 <pavel at 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 at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20220201/32e35984/attachment.html>