On 10/05/2009 11:44 PM, Roland McGrath wrote:
I can't decide whether that case is kosher, I can argue both sides. Shouldn't the parent either claim addresses of its child, or not have that DIE as a child in a first place?
No, I'm pretty confident that's kosher as it is.
Well, currently dwarf_getscopes assumes that every child is a strict PC-subset of the parent, so it won't ever find a PC in such unclaimed children.
Similarly, dwarf_getfuncs won't return nested functions either. I see no real way to fix these without traversing nearly all DIEs. :(
The DIE nesting there indicates the lexical scope of the inner function. It's right for it to be there, so that you can tell e.g. that the DW_TAG_variable entries of its parent function are visible inside that inner DW_TAG_subprogram scope.
In other nested lexical scopes, like a C++ class method, you get a top-level DW_TAG_subprogram DIE with a DW_AT_specification to the nested definition. Wouldn't that be a better way for these nested functions to generate dwarf too?
Josh