Re: [rfa/dwarf/doc] Inter-compilation-unit reference support for partial DIEs

[Jim Blandy <jimb at redhat dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Fri, Aug 06, 2004 at 05:22:56PM -0500, Jim Blandy wrote:
> > 
> > Daniel Jacobowitz <drow@false.org> writes:
> > > So I can merge the two structures if you would like.  I can't think of
> > > any fundamental problem.
> > 
> > This would also remove the special case for the stack-allocated
> > compilation unit structure in dwarf2_build_psymtabs_hard, right?
> 
> No, that's a different thing entirely.  The only way to get rid of it
> would be to stop stack-allocating it, and allocate/free it each time
> through the loop.
> 
> The more I look at it the less inclined I am to merge dwarf2_cu and
> dwarf2_per_cu_data; I'd rather find acceptable names for them.  The
> dwarf2_per_cu_data is all the information we need to keep for every
> compilation unit, including the not-read-in ones.  The dwarf2_cu is all
> the information we need to keep around for read-in ones.  I like the
> explicit separation.
> 
> The only thing weird about the list manipulation is, well, the list
> pointer is only needed for read-in ones... so it went in the second
> structure.
> 
> How do you feel about this?

Well, you understand that I'm trying to get at really has nothing to
do with correctness, or performance, or anything like that.  I want
the structures to look more "normal".  I don't see that they task
they're carrying out is so strange that they shouldn't match the
idioms everyone's got wired into their heads better, to maximize the
chances that they get the big picture from a casual read.

How about putting the 'read_in' links all in the always-present
structs?  That way the linked list looks more like a linked list: it
actually points to an instance of the same structure that contains it.
And we can blow four bytes per CU.  Then, if we need it, put a link in
the structure for read-in CU's back to the always-present structs.