Re: Transparent imports of partial units

[Petr Machata <pmachata@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Mark Wielaard <mjw@redhat.com> writes:

> So, assuming we can use the long int padding field as Dwarf_Die pointer,

In other words, do we want to keep backward compatibility on LLP64
architectures?  I know Widnows do use this model, do we care?  Any
Unices with this model out there?  FWIW, x32 and (MIPS) n32 are both
ILP32 ABI's.

If this is a concern, we can keep it as is and use the value as an index
into an internal array of cached DIE's instead of raw pointer.

Actually, we may want to choose this way also because it allows us to
take only part of the remaining space, and save the rest for rainy day.
But the savings can't be too aggresive.  We can save a bit by storing
import points at target partial unit instead of putting it all together
at Dwarf, but the space complexity will still be essentially O(number of
DIE's in Dwarf).  I'm reluctantly proposing 24 bits as a "good enough
for everybody" number.  That would allow us to index 16 million import
paths to any partial units, and save 8 bits for whatever else we need.
But I'm not quite convinced myself, I have Dwarfs with 16 million DIE's
in my personal dwgrep test bench.

> each Dwarf_Die returned by dwarf_child_aggregate (ugly name!) that came

Not only dwarf_child_aggregate, also dwarf_siblingof_aggregate.  I think
it's perfectly valid to have an import-point in the middle of sibling
chain, or to have several import points in one chain.

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

That's the idea.

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

Yeah, they would just have to throw our pointer/index thingy into the
mix.  Having an interface for this seems more prudent, and would allow
us to tweak the exact representation should the need arise (such as when
we run out of space).

Thanks,
Petr