This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Transparent imports of partial units
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 31 Oct 2014 15:40:03 +0100
- Subject: Re: Transparent imports of partial units
On Tue, 2014-10-14 at 02:24 +0200, Petr Machata wrote:
> 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?
Agreed. I updated systemtap some time ago and there were surprisingly
many places that needed to be updated. I hope I caught them all.
> 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.
That already sounds like an (abstract) plan :)
So, assuming we can use the long int padding field as Dwarf_Die pointer,
each Dwarf_Die returned by dwarf_child_aggregate (ugly name!) that came
through an imported_unit DIE would point back to that imported_unit and
dwarf_sibling_aggregate would propagate that back pointer to each
sibling. And when there are no more sibling and the back pointer is set,
then dwarf_sibling_aggregate would continue at the imported DIE pointed
to and take the next sibling there?
I don't immediately see any drawbacks. The only thing I can think of is
that we might want to provide a equal/identity function for Dwarf_Die,
in case people want to know whether two "raw" DIEs are really the same
(although people can already do that given the addr and CU fields I see
now).
> 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.
Yes, this only happens to work currently because dwz only uses import
DIEs as "top-level" CU children, so the DIEs you are feeding these
functions probably don't have any children that are imported units, but
if they will in the future then things break unexpectedly.
Thanks,
Mark