From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5798 invoked by alias); 30 Sep 2003 22:13:58 -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 5790 invoked from network); 30 Sep 2003 22:13:57 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 30 Sep 2003 22:13:57 -0000 Received: by zenia.home (Postfix, from userid 5433) id 80F7720766; Tue, 30 Sep 2003 17:09:39 -0500 (EST) To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni Subject: Re: [rfa] add 'parent' field to struct die_info References: From: Jim Blandy Date: Tue, 30 Sep 2003 22:13:00 -0000 In-Reply-To: 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: 2003-09/txt/msg00669.txt.bz2 David Carlton writes: > This patch adds a 'parent' field to struct die_info. There's no way > to get that information out of our current data structures, and it is > necessary for nested type support: die A might reference a type die B > via DW_AT_specification, and to correctly deal with the possibility > that B might be a nested type, we'll have to know B's parent (if any). > (See the thread starting in > .) I was > going to do this as part of a big nested type patch, but I figured > Elena was going to ask me to commit this part separately anyways. :-) > (But I would appreciate it if you could review it quickly: it's > simple.) > > While I was at it, I replaced the existing 'has_children' and 'next' > fields by 'child' and 'sibling' fields: it seems clearer to me that > way. The result of this is that the function 'sibling_die' isn't > really pulling its weight any more; I left it in there for now, > though. Looks great --- please commit. Adding the parent pointer is great. But I also really appreciate the child/sibling rearrangement... the way it stands is really confusing, and I think this is much more intuitive. It doesn't seem to me like the 'abbrev' field of 'struct die_info' is being used for anything very important; removing that would bring 'struct die_info' back to the size it has now. I wonder if there isn't a clearer way to read the trees. The read_die_and_children / read_die_and_siblings pair is harder for me to understand than it seems like it should be. But the burden is on me to show that there's a better way...