From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17216 invoked by alias); 1 Oct 2003 17:24:07 -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 17194 invoked from network); 1 Oct 2003 17:24:06 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Oct 2003 17:24:06 -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 h91HO5129654 for ; Wed, 1 Oct 2003 13:24:05 -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 h91HO5c17338 for ; Wed, 1 Oct 2003 13:24:05 -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 h91HO4TX002256; Wed, 1 Oct 2003 13:24:04 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 991C92CCB2; Wed, 1 Oct 2003 13:34:21 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16251.4125.307628.200025@localhost.redhat.com> Date: Wed, 01 Oct 2003 17:24:00 -0000 To: David Carlton Cc: Jim Blandy , gdb-patches@sources.redhat.com, Elena Zannoni Subject: Re: [rfa] add 'parent' field to struct die_info In-Reply-To: References: X-SW-Source: 2003-10/txt/msg00005.txt.bz2 David Carlton writes: > On 30 Sep 2003 17:09:38 -0500, Jim Blandy said: > > > Looks great --- please commit. > > Thanks, done. > > > 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. > > That was my attitude, too: before, we were too closely tied to the > data structure that the debug info was originally stored in, for no > good reason. May I suggest to add a comment where the structure is defined that explains in plain English the structure/relations of the dies? >From the Dwarf manual: "The ownership relation of debugging information entries is achieved naturally because the debugging information is represented as a tree. The nodes of the tree are the debugging information entries themselves. The child entries of any node are exactly those debugging information entries owned by that node. While the ownership relation of the debugging information entries is represented as a tree, other relations among the entries exist, for example, a pointer from an entry representing a variable to another entry representing the type of that variable. If all such relations are taken into account, the debugging entries form a graph, not a tree. The tree itself is represented by flattening it in prefix order. 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." I think this would help a bit too (of course a bit shortened/paraphrased). elena