From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0780540109030994111==" MIME-Version: 1.0 From: Petr Machata To: elfutils-devel@lists.fedorahosted.org Subject: Re: Transparent imports of partial units Date: Fri, 31 Oct 2014 19:26:02 +0100 Message-ID: In-Reply-To: 1414766403.18323.50.camel@bordewijk.wildebeest.org --===============0780540109030994111== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Mark Wielaard 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 --===============0780540109030994111==--