From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7611 invoked by alias); 8 Aug 2004 04:42:53 -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 7597 invoked from network); 8 Aug 2004 04:42:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Aug 2004 04:42:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i784gqe1003156 for ; Sun, 8 Aug 2004 00:42:52 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i784goa31411; Sun, 8 Aug 2004 00:42:51 -0400 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, ezannoni@redhat.com Subject: Re: [rfa/dwarf/doc] Inter-compilation-unit reference support for partial DIEs 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> From: Jim Blandy Date: Sun, 08 Aug 2004 04:42:00 -0000 In-Reply-To: <20040807220115.GA25874@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg00232.txt.bz2 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.