This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sat, Aug 07, 2004 at 11:39:53PM -0500, Jim Blandy wrote:
> 
> 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.

You need to make this decision one way or another, because the current
idiom makes perfect sense to me, so the change would gain me no clarity
at the expense of an extra pointer.  If you'd like me to make that
change, I'll do it.

The object is a struct dwarf2_per_cu_data.  Each is either in the
read-in or not-read-in state; if it is in the read-in state there is a
dwarf2_cu which is owned by this object, containing additional state
variables.  One of the additional state variables is the pointer to the
next item in the list of read-in objects.

There already is a pointer back to the always-present struct, IIRC.  It
would be nice to kill it some day.

-- 
Daniel Jacobowitz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]