headers
Elena Zannoni | 1 Oct 2003 19:34
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info

David Carlton writes:
 > On 30 Sep 2003 17:09:38 -0500, Jim Blandy <jimb <at> redhat.com> 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
(Continue reading)

Permalink | Reply |
headers
Jim Blandy | 2 Oct 2003 06:03
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info


Elena Zannoni <ezannoni <at> redhat.com> 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?

2003-10-01  Jim Blandy  <jimb <at> redhat.com>

	* 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.  */
(Continue reading)

Permalink | Reply |
headers
Elena Zannoni | 2 Oct 2003 17:54
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info

Jim Blandy writes:
 > 
 > Elena Zannoni <ezannoni <at> redhat.com> 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
(Continue reading)

Permalink | Reply |
headers
Jim Blandy | 2 Oct 2003 17:52
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info


Elena Zannoni <ezannoni <at> redhat.com> 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.
Permalink | Reply |
headers
Elena Zannoni | 2 Oct 2003 18:10
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info

Jim Blandy writes:
 > 
 > Elena Zannoni <ezannoni <at> redhat.com> 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
Permalink | Reply |

Gmane