From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18853 invoked by alias); 2 Oct 2003 16:00:35 -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 18846 invoked from network); 2 Oct 2003 16:00:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2003 16:00:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h92G0Y119324 for ; Thu, 2 Oct 2003 12:00:34 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h92G0Yc08717 for ; Thu, 2 Oct 2003 12:00:34 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h92G0Wbe000347; Thu, 2 Oct 2003 12:00:33 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 7B0952CCAC; Thu, 2 Oct 2003 12:10:50 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16252.19978.310797.582904@localhost.redhat.com> Date: Thu, 02 Oct 2003 16:00:00 -0000 To: Jim Blandy Cc: Elena Zannoni , David Carlton , gdb-patches@sources.redhat.com Subject: Re: [rfa] add 'parent' field to struct die_info In-Reply-To: References: <16251.4125.307628.200025@localhost.redhat.com> <16252.19002.705540.309926@localhost.redhat.com> X-SW-Source: 2003-10/txt/msg00030.txt.bz2 Jim Blandy writes: > > 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. whatever