[Dwarf-Discuss] Finding parent of a DIE?

[Michael Eager]

A bit of background --

DWARF is intended as a object file format, not as the format for an internal
symbol table.  The emphasis is on compact representation, rather than on ease
of search.  This means that redundant data (like back chains) are not provided.

It is anticipated that a DWARF consumer will read the DWARF data and use it
to populate internal tables.  These tables would likely include back and
cross links to make finding parents or members easier.

Ron Louzon wrote:
> 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
>> 
> 
> 
> 
> _______________________________________________ Dwarf-Discuss mailing list 
> Dwarf-Discuss at lists.dwarfstd.org 
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> 


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077