From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4800 invoked by alias); 8 Aug 2004 18:17:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4791 invoked from network); 8 Aug 2004 18:17:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 8 Aug 2004 18:17:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BtsEn-0006nV-7Q; Sun, 08 Aug 2004 14:17:41 -0400 Date: Sun, 08 Aug 2004 18:17:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com, ezannoni@redhat.com Subject: Re: [rfa/dwarf/doc] Inter-compilation-unit reference support for partial DIEs Message-ID: <20040808181741.GB26005@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com, ezannoni@redhat.com References: <20040420170855.GA31548@nevyn.them.org> <20040617034201.GD23443@nevyn.them.org> <20040715184431.GA25807@nevyn.them.org> <20040804230536.GA30848@nevyn.them.org> <20040805180341.GB9011@nevyn.them.org> <20040807220115.GA25874@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00265.txt.bz2 On Sat, Aug 07, 2004 at 11:39:53PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Fri, Aug 06, 2004 at 05:22:56PM -0500, Jim Blandy wrote: > > > > > > Daniel Jacobowitz 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