From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1998487157360701131==" MIME-Version: 1.0 From: Petr Machata To: elfutils-devel@lists.fedorahosted.org Subject: Transparent imports of partial units Date: Tue, 14 Oct 2014 02:24:48 +0200 Message-ID: --===============1998487157360701131== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi there, with dwz out there in the wild and being used, clients will generally have to deal with handling of partial units. (They always kinda had to, but now they have to for real.) In theory, every time that you call dwarf_child or dwarf_siblingof, you should do a little dance of checking whether the DIE happens to be DW_TAG_imported_unit, and if yes, locate that unit and look at its children, possibly recursively resolving more imported units. You then should retract along the same lines when dwarf_siblingof hits the wall. It seems inefficient to have to replicate this logic in each client. We have interfaces for transparent integration of attributes, why not do something similar for partial unit imports? Currently partial units are only handled in __libdw_visit_scopes. I don't have any particular plan, but at least dwarf_child and dwarf_siblingof seem like they shoud have transparent-importing twins. My abstract ideas count on caching DIE's of the integration points and referencing them through the now-unused padding field of Dwarf_Die. Then when dwarf_siblingof hits the end of DIE chain, it checks this field and possibly continues the iteration there. On top of the above, there are places in libdw where dwarf_child and dwarf_siblingof are called. E.g. in dwarf_aggregate_size, there could in theory be an import point between DW_TAG_enumeration_type and its DW_TAG_enumerator's. That's not currently handled. It seems like in these sorts of cases, we should use the new interfaces. Opinions? Thanks, Petr --===============1998487157360701131==--