[Dwarf-Discuss] Interaction between aranges and unit proposals

[Eric Christopher]

On Tue, Apr 1, 2014 at 4:38 AM, Mark Wielaard <mjw at redhat.com> wrote:
> Hi,
>
> I have been pondering the various aranges proposals and how they
> interact with the change to merge the units proposal. It looks like the
> intent of two proposals is diminished by two other proposals.
>
> 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
>
> Together when adopted makes life for a debugger much easier. You would
> scan the .debug_aranges section, note the addresses, see whether all CUs
> from the .debug_info section are covered and then don't need to load any
> other information if no address match is found. Given that the
> main .debug_info/.debug_abbrev sections are often huge and that some
> programs contain lots of modules not having to map them all in is a
> great benefit.
>
> But then there are also the following proposals:
>
> Type Unit Merge
> http://dwarfstd.org/ShowIssue.php?issue=130526.1
>
> Ambiguity in DWARF4 of debug_info_offset in .debug_aranges
> http://dwarfstd.org/ShowIssue.php?issue=100816.1
>
> Together these proposals counter the first two proposals. Since when
> adopted the first would introduce type units in the main .debug_info
> section and then the second would remove .debug_aranges for those units.
> Which would bring us back to the original situation that you cannot just
> scan the .debug_aranges for an address and check whether all units
> in .debug_info are covered. So you will again need to load and scan them
> too when trying to match an address.
>
> Is there a way to reconcile these proposals so they keep the benefit of
> both (quick/complete address scan without having to load/parse bulk data
> and simplifying the DWARF data structures by combining various units in
> one section)?
>

Absolutely a fan. Knowing what various consumers need is going to be
key for any tables to speed up access.

> 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.
>

We could do this, but I think adding one for every type unit would be
a bit wasteful. Since type units are going to have a flag in the
header would it be possible for you to notice that when looking
through the units? I'm not sure how you know that you have complete
coverage so I'm just throwing out words here, could you provide a bit
of a description of how this works for me if you don't mind?

-eric