[Dwarf-Discuss] Interaction between aranges and unit proposals

Mark Wielaard mjw at redhat.com
Tue Apr 1 04:38:47 PDT 2014


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

debug_aranges and address-less CUs

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

Ambiguity in DWARF4 of debug_info_offset in .debug_aranges

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)?

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.



More information about the Dwarf-Discuss mailing list