[Dwarf-Discuss] Interaction between aranges and unit proposals

[Cary Coutant]

> To make it possible to quickly see whether an address (range) is covered
> by an ELF file containing DWARF information two proposals were made:
>
> aranges does not have debug info length
> http://dwarfstd.org/ShowIssue.php?issue=100430.1
>
> debug_aranges and address-less CUs
> http://dwarfstd.org/ShowIssue.php?issue=100430.2

We dropped the first and made the second a best practice.

> But then there are also the following proposals:
>
> Type Unit Merge
> http://dwarfstd.org/ShowIssue.php?issue=130526.1

Yes, this is pretty much why we dropped the first proposal.

> Ambiguity in DWARF4 of debug_info_offset in .debug_aranges
> http://dwarfstd.org/ShowIssue.php?issue=100816.1

I don't see how this one is relevant. This was really just an
editorial change -- .debug_aranges physically could not point to a
.debug_types section. In addition, with the type unit merge proposal,
it becomes completely irrelevant (there will be no .debug_types
section at all).

> One way might be to reverse the last proposal. Instead of removing the
> aranges for type units (which did indeed not make much sense in the
> split .debug_info/.debug_type approach), add an empty aranges header if
> a type unit appears in .debug_info in the way of the second proposal for
> address-less CUs.

I don't really like the idea of having aranges sections for type
units. It would be nicer to keep type units separate, since there are
*so* many more of them than there are compunits, but for the
accelerator table proposal, we needed a unified address space for the
two, and this was the simplest way to accomplish that.

I think it's fine for a consumer to first assume that the
.debug_aranges table is complete, but if an address lookup fails, then
it can scan the .debug_info section, hopping from one CU/TU to the
next, looking for CUs that aren't covered by .debug_aranges tables.
Having the debug_info length field in the aranges table would help,
but even then, it's not clear to me how much it will help.

With unified CUs and TUs, this scan will be costly with or without the
length field -- for every CU, you'll probably have to skip over dozens
or hundreds of TUs. It might help if we could guarantee that all CUs
precede all TUs, but the only reasonable way to do that is to keep
them in separate sections to begin with! Adding empty aranges tables
for the TUs will bloat the .debug_aranges section significantly, and
it would add a burden on the producers to make sure that the
.debug_aranges contributions are in the same COMDAT group as the TU
itself (GCC, for example, still doesn't put related sections in the
same group).

I think if we can come up with a way to have index entries in the
accelerator tables point to either a CU or a TU without having a
unified address space, we wouldn't need to merge .debug_info and
.debug_types, and we could reopen the first proposal.

-cary