dtrace discuss - Feb 2010 - ustack() and trouble with leaf functions

Hi all,

I''m using dtrace (SunOS 5.10 Generic_142900-03 sun4v sparc) to track
the
ustack of certain troublesome function calls, but leaf functions which 
don''t have a stack frame of their own are causing problems.

For example, dtrace''s ustack() might report the following:
a.out`frameless_leaf+0x10
a.out`random_function+0x9c

...when in fact random_function+0x9c is actually a call to 
some_other_function. Printing the stack trace from dbx shows what''s 
really going on:

[1] frameless_leaf()
[2] true_caller()
[3] some_other_function()
[4] random_function()

I tried uaddr(uregs[R_O7]), but it may point to some_other_function 
rather than true_caller, or complete garbage for other stack frames.

Is this a known limitation/bug? For now I''m using the O7 trick and 
post-processing to remove the most glaring deficiencies but a real 
solution would be nice.

Regards,
Ryan

On Fri, Feb 5, 2010 at 7:10 AM, Ryan Johnson <ryanjohn at ece.cmu.edu>
wrote:
>
> Is this a known limitation/bug? For now I''m using the O7 trick and
> post-processing to remove the most glaring deficiencies but a real solution
> would be nice.
>
Yes, this is a known limitation.  The documentation talks about the
problem with tail-call optimization:

http://docs.sun.com/app/docs/doc/817-6223/6mlkidln8?a=view

Chad

On 2/5/2010 1:19 PM, Chad Mynhier wrote:
> On Fri, Feb 5, 2010 at 7:10 AM, Ryan Johnson<ryanjohn at ece.cmu.edu>
wrote:
>    
>> Is this a known limitation/bug? For now I''m using the O7 trick
and
>> post-processing to remove the most glaring deficiencies but a real
solution
>> would be nice.
>>      
> Yes, this is a known limitation.  The documentation talks about the
> problem with tail-call optimization:
>
> http://docs.sun.com/app/docs/doc/817-6223/6mlkidln8?a=view
>    
This isn''t a tail call issue. The leaf function has the true
caller''s
return address (in O7), but never creates a stack frame. The lack of a 
stack frame is what confuses dtrace, I think.

Ryan

On Fri, Feb 5, 2010 at 9:40 AM, Ryan Johnson <ryanjohn at ece.cmu.edu>
wrote:
> On 2/5/2010 1:19 PM, Chad Mynhier wrote:
>>
>> On Fri, Feb 5, 2010 at 7:10 AM, Ryan Johnson<ryanjohn at
ece.cmu.edu> ?wrote:
>>
>>>
>>> Is this a known limitation/bug? For now I''m using the O7
trick and
>>> post-processing to remove the most glaring deficiencies but a real
>>> solution
>>> would be nice.
>>>
>>
>> Yes, this is a known limitation. ?The documentation talks about the
>> problem with tail-call optimization:
>>
>> http://docs.sun.com/app/docs/doc/817-6223/6mlkidln8?a=view
>>
>
> This isn''t a tail call issue. The leaf function has the true
caller''s return
> address (in O7), but never creates a stack frame. The lack of a stack frame
> is what confuses dtrace, I think.
Yes.  DTrace walks the stack frames to generate the stack trace.  If
there''s no stack frame, it won''t show up.

I haven''t verified this with the code yet, but I assume DTrace skips
the top stack frame because it gets the information otherwise.  That
would explain why you don''t see true_caller().

I''m a little bit confused as to why you don''t see
some_other_function(), though.  It seems that this one would at least
be showing up,  Is this a case of tail-call optimization?

Chad

On 2/5/2010 6:07 PM, Chad Mynhier wrote:
> I''m a little bit confused as to why you don''t see
> some_other_function(), though.  It seems that this one would at least
> be showing up,  Is this a case of tail-call optimization?
>    
Actually, that could be. Most of the time O7 fills in the only missing 
link, so it may be that the ones which are left got optimized.

Any chance of dtrace becoming more aware of these frameless leaf 
functions? O7''s pretty easy to get at, and it would be nice for it to
go
into the stack trace directly.

Regards,
Ryan