From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============6433650420167301078=="
MIME-Version: 1.0
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Transparent imports of partial units
Date: Fri, 31 Oct 2014 15:40:03 +0100
Message-ID: <1414766403.18323.50.camel@bordewijk.wildebeest.org>
In-Reply-To: m2siirjy5r.fsf@redhat.com

--===============6433650420167301078==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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

--===============6433650420167301078==--