From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9788 invoked by alias); 2 Oct 2003 15:44:20 -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 9780 invoked from network); 2 Oct 2003 15:44:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2003 15:44:19 -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 h92FiJ114710 for ; Thu, 2 Oct 2003 11:44:19 -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 h92FiJc02313 for ; Thu, 2 Oct 2003 11:44:19 -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 h92FiHbe030569; Thu, 2 Oct 2003 11:44:17 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id DA5632CCAC; Thu, 2 Oct 2003 11:54:34 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16252.19002.705540.309926@localhost.redhat.com> Date: Thu, 02 Oct 2003 15:44: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> X-SW-Source: 2003-10/txt/msg00028.txt.bz2 Jim Blandy writes: > > Elena Zannoni writes: > > May I suggest to add a comment where the structure is defined that explains > > in plain English the structure/relations of the dies? > > How's this? > The thing I am trying to capture is the organization of the tree/graph, i.e. how the various functions that loop through the entries following the pointers navigate the structure. I get often confused by statements like: if (dies->has_children) { child_die = dies->next; which now is much clearer anyway. I think basically we need something to capture the definition of next die to be visited. Like below. 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. elena > 2003-10-01 Jim Blandy > > * dwarf2read.c (struct die_info): Doc fix. > > Index: gdb/dwarf2read.c > =================================================================== > RCS file: /cvs/src/src/gdb/dwarf2read.c,v > retrieving revision 1.109 > diff -c -c -F'^(' -r1.109 dwarf2read.c > *** gdb/dwarf2read.c 30 Sep 2003 22:29:28 -0000 1.109 > --- gdb/dwarf2read.c 2 Oct 2003 04:06:12 -0000 > *************** > *** 320,328 **** > --- 320,335 ---- > unsigned int num_attrs; /* Number of attributes */ > struct attribute *attrs; /* An array of attributes */ > struct die_info *next_ref; /* Next die in ref hash table */ > + > + /* The dies in a compilation unit form an n-ary tree. PARENT > + points to this die's parent; CHILD points to the first child of > + this node; and all the children of a given node are chained > + together via their SIBLING fields, terminated by a die whose > + tag is zero. */ > struct die_info *child; /* Its first child, if any. */ > struct die_info *sibling; /* Its next sibling, if any. */ > struct die_info *parent; /* Its parent, if any. */ > + > struct type *type; /* Cached type information */ > }; >