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

[Jim Blandy <jimb@redhat.com>]

David Carlton <carlton@kealia.com> writes:
> This patch adds a 'parent' field to struct die_info.  There's no way
> to get that information out of our current data structures, and it is
> necessary for nested type support: die A might reference a type die B
> via DW_AT_specification, and to correctly deal with the possibility
> that B might be a nested type, we'll have to know B's parent (if any).
> (See the thread starting in
> <http://sources.redhat.com/ml/gdb/2003-05/msg00173.html>.)  I was
> going to do this as part of a big nested type patch, but I figured
> Elena was going to ask me to commit this part separately anyways. :-)
> (But I would appreciate it if you could review it quickly: it's
> simple.)
> 
> While I was at it, I replaced the existing 'has_children' and 'next'
> fields by 'child' and 'sibling' fields: it seems clearer to me that
> way.  The result of this is that the function 'sibling_die' isn't
> really pulling its weight any more; I left it in there for now,
> though.

Looks great --- please commit.

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.

It doesn't seem to me like the 'abbrev' field of 'struct die_info' is
being used for anything very important; removing that would bring
'struct die_info' back to the size it has now.

I wonder if there isn't a clearer way to read the trees.  The
read_die_and_children / read_die_and_siblings pair is harder for me to
understand than it seems like it should be.  But the burden is on me
to show that there's a better way...