[Dwarf-Discuss] Finding parent of a DIE?

[Ron Louzon]

That is what I thought but I wanted to be sure.  I am trying to retrieve address and type information for static variables which are defined in class member methods.  Up until now, I have been working with Greenhills GNU C++ compiler output and that compiler lays out the DWARF DIEs in a nice hierarchical format:   Static variables are children of method DIEs;  Methods are children of classes which are children of Compilation units.  

I have just started working with another version of the GNU C++ compiler and it puts all of the member method definitions at the end of the compilation unit and the DIEs are not children of their respective classes.  It does list the member function declarations in the hierarchical layout but those declarations do not include any information for contained variables.   This forces me to work backwards from a member function definition to find its owner class.

- Ron

--- On Fri, 7/24/09, Roland McGrath <roland at redhat.com> wrote:

> From: Roland McGrath <roland at redhat.com>
> Subject: Re: [Dwarf-Discuss] Finding parent of a DIE?
> To: "Ron Louzon" <louzonr at yahoo.com>
> Cc: dwarf-discuss at lists.dwarfstd.org
> Date: Friday, July 24, 2009, 4:26 PM
> > Is there any straight-forward
> method to find the parent DIE of a selected
> > DIE in the DWARF data?? For example, if I have a
> DIE with offset 0x1640,
> > which is a DW_TAG_subprogram DIE, is there any way to
> determine the
> > parent of that DIE?
> 
> Nope.? You have to walk the tree from the root until
> you meet yourself, or
> cache state to optimize that.? Note that when you are
> looking for your
> parent, you can skip some useless parts of the walk just by
> looking at a
> DIE's DW_AT_sibling and quickly seeing that it doesn't
> "own" your offset.
> 
> But also note that if there are "indirect" children via
> DW_TAG_imported_unit
> (a generic compression technique for DWARF trees), then
> your logical parent
> might be in another CU and then you have to know which CU
> to start with (or
> walk them all), walk its tree and look for the parent of a
> DW_TAG_imported_unit that points to the CU that's your
> parent.
> 
> In short, the way you probably want to approach consuming
> DWARF trees is by
> keeping state about your tree walks, caches of paths taken
> to reach DIEs
> you can look up to follow the random-access pointers in
> attributes of class
> reference, etc.
> 
> 
> Thanks,
> Roland
>