On Tue, 2018-01-30 at 13:34 +0100, Mark Wielaard wrote: > The dwarf_nextcu and dwarf_next_unit functions provide information to > construct the offset to construct the associated CU DIE using dwarf_offdie > or dwarf_offdie_types. This requires the user to know beforehand where > to DIE data is stored (in the .debug_info or .debug_types section). > For type units one also needs to use the type offset to create the actual > type DIE. In DWARF5 DIEs can come from even more data locations. And there > are also skeleton units which require the user to find the associated > split compile unit DIE (which would come from a different file). > > The new dwarf_get_units function simplifies iterating over the units in > a DWARF file. It doesn't require the user to know where the DIE data is > stored, it will automagically iterate over all know data sources (sections) > returning the Dwarf_CU and the associated Dwarf_Die if requested. If the > user requests to know the associated "subdie" it will also be resolved. > > This implementation returns the correct subdie for type units. A future > version will also handle skeleton units and return the associated skeleton > DIE and split unit DIE. > > readelf has been adapted to use the new iterator and print the new DWARF5 > unit header information (which it gets through dwarf_cu_die). The new > interface hides which section exactly to iterate on (by design). readelf > works around that by "cheating". It sets up a Dwarf_CU so that it gets > the data from the right section, using the (normally) internal data > structure.
I pushed this to master.
