From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8681 invoked by alias); 7 Aug 2004 22:01:17 -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 8673 invoked from network); 7 Aug 2004 22:01:17 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 7 Aug 2004 22:01:17 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BtZFb-0006ki-Ul; Sat, 07 Aug 2004 18:01:16 -0400 Date: Sat, 07 Aug 2004 22:01: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: <20040807220115.GA25874@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> 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/msg00223.txt.bz2 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? -- Daniel Jacobowitz