Re: Dwarf expertise needed

[Sami Wagiaalla <swagiaal@redhat.com>]

Roland,

First of all thank you for the thorough reply. I now see issues that I 
have not seen before.

Roland McGrath wrote:
>> What I am expecting it to return is the the scopes from narrowest to and 
>> including the scope corresponding to the concrete inlined instance, then 
>> the function within which it has been inlined and the scopes containing 
>> that; as per the dwarf spec. Is this a correct understanding of what the 
>> function /should/ do ? And should I fix the function, write a parallel 
>> one that does what i want, or is there another code pathway to get it ?
>>     
>
> I don't know why you call that "as per the dwarf spec".  (The spec says
> what the format means, not what any function does.)
>   
I just meant to say "scope" in the dwarf spec sense, as opposed to 
lexical scope.

[...]
> Contemplating it now, I don't think it is really so quite confusing what's
> required, at least for frame_base.  I probably need to think more about the
> nested function cases, and might confuse myself again doing it.  I also
> haven't thought of anything other than frame_base that a dwarf_getscopes
> caller might need from a physically relevant but lexically disjoint DIE.
> Something else I'm overlooking might have different requirements.  To get
> the right frame_base, I think a straightforward change of the getscopes
> interface can cover it.  As well as the array of lexical scope DIEs, it
> would yield a parallel array of Dwarf_Die pointers.  Each scope[i]
> corresponds to base_scope[i].  Locations from scope[i] are resolved in the
> physical context of base_scope[i].  For simple cases, scope[i]==base_scope[i].
> When scope[i] is an inlined_subroutine, base_scope[i] is the containing
> subprogram that has the actual code.  So, in all cases, base_scope[i] is
> where you need to look for a frame_base attribute when scope[i] leads you to
> a location that uses frame_base.
>
> But I'd like to try to think of other things than frame_base one might
> need, and think through the nested function cases, before deciding what
> exact change the interface should get.
>   
That is cool.

If it turns out that frame_base is the only instance then how about a 
function get_framebase that is smart enough to figure out where the 
correct frame base is. That way you help the client not make that 
mistake. Or get_* for each attribute that needs the abstract instance of 
the function.


> Right now, if your test cases do not require the frame_base attribute,
> then we can just work on fixing any bugs in the implementation of the
> current definition of the dwarf_getscopes interface as I described it above.  
>
> dwarf_getscopes has always been for the source-level semantic view of
> lexical identifier scope.  For other purposes, you might instead be
> looking for the physical structural view of the compiled code.  For
> example, if you are displaying the running code in an inlined instance
> and want to visualize "this code inlined into here", or are synthesizing
> fictional call frames for a semantic backtrace including inlined calls.
> (If you are only displaying the source location of the caller, you have
> the call_{file,line,column} attributes at hand and don't need the
> caller's DIE at all.)  dwarf_getscopes_die does exactly this, though its
> name and comments would lead you to think it acts like dwarf_getscopes
> when given a DIE that is part of a concrete inlined instance tree.
> (That's what it probably should do, and there should be a different call
> for the simple structural visitor.)  So with 0.128 code, you can use
> dwarf_getscopes on a PC, then take a scope[i] of interest such as an
> inlined_subroutine DIE, and pass it to dwarf_getscopes_die to see its
> caller's scope context.
>   
That will do, although I think there might be a bug there :(. Let me 
double check.