From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16779 invoked by alias); 2 Oct 2003 15:57:22 -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 16771 invoked from network); 2 Oct 2003 15:57:22 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 2 Oct 2003 15:57:22 -0000 Received: by zenia.home (Postfix, from userid 5433) id 70C4520766; Thu, 2 Oct 2003 10:52:51 -0500 (EST) To: Elena Zannoni Cc: David Carlton , gdb-patches@sources.redhat.com Subject: Re: [rfa] add 'parent' field to struct die_info References: <16251.4125.307628.200025@localhost.redhat.com> <16252.19002.705540.309926@localhost.redhat.com> From: Jim Blandy Date: Thu, 02 Oct 2003 15:57:00 -0000 In-Reply-To: <16252.19002.705540.309926@localhost.redhat.com> 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-10/txt/msg00029.txt.bz2 Elena Zannoni writes: > Each debugging information entry is defined either to have child > entries or not to have child entries. If an entry is defined not to > have children, the next physically succeeding entry is a sibling. If > an entry is defined to have children, the next physically succeeding > entry is its first child. Additional children are represented as > siblings of the first child. A chain of sibling entries is terminated > by a null entry. Sure, that sort of explanation would be appropriate for the die reading code, but I think it would just be confusing for 'struct die_info'. Once we've built the die tree in memory, all that detail is gone, and you've just got the pure tree structure. There's no concept of "the next physically succeeding entry", for example.