> Not generally possible: I guess this is technically true, thanks to
> trampolines, tail calls, and JMPL whose source registers have probably been
> clobbered. However, we should at least be able to detect vanilla CALL
> reliably by decoding %i7 (I've never heard of a compiler clobbering it). The
> attached scripts do this. The dtrace script reads in the instruction at %i7,
> decodes it and computes the target when possible, and emits the result at the
> head of each stack trace. The awk script (which takes the dtrace script's
> output as input) then checks whether i7's target points to the same function
> as the leaf's caller and decide whether to filter it out.
It it not generally possible to determine the the probe fires whether or not
the thread is currently executing in leaf context. All symbolic translations
happens in user-land after the fact for both ustack() and uaddr().
> Running the two scripts on a process, I got 13.5k total samples, with with
> 214 of those unable to read %i7 for some reason; of the valid samples, 8.2k
> had %i7's target point to a different function than the leaf.
>
> I've checked source code for a smattering of the samples, and every time the
> i7-enhanced stack trace is the correct one.
>
> Maybe this won't ever get baked into dtrace, but at least there's a
> workaround now if other folks need it.
What we could do is have the ustack() action record %o7 as well and then figure
out in user-land whether or not it's relevant.
> Also, it might be good to update the wiki with this gotcha. Missing tail
> calls is one thing... silently missing legitimate callers who made a stack
> frame is pretty annoying (and makes profiling significantly less useful if
> you're hunting for the caller of that expensive function).
Good idea. Propose some changes to the list and we'll get it reviewed.
Thanks.
Adam
> Regards,
> Ryan
>
> On 7/19/2010 7:55 PM, Adam Leventhal wrote:
>> Hey Ryan,
>>
>> We have special logic in pid provider entry and return probes to account for
>> the fact that they execute in leaf call context. Unfortunately, this is not
>> generally possible.
>>
>> Search for uses of CPU_DTRACE_ENTRY on cvs.opensolaris.org.
>>
>> Adam
>>
>> On Jul 14, 2010, at 3:05 AM, Ryan Johnson wrote:
>>
>>
>>> Hi all,
>>>
>>> There was a discussion about this a while back, but now some new
>>> information has come to light:
>>>
>>> Consider the situation where a thread calls a leaf function which does not
>>> create a stack frame (such as atomic_*). The following toy program
>>> demonstrates this scenario:
>>>
>>> --- begin backtrace.c ------------
>>> #include<atomic.h>
>>> unsigned int x;
>>> int foo() {
>>> int y = 1;
>>> while(y != 100) {
>>> y = atomic_swap_32(&x, y);
>>> }
>>> return x;
>>> }
>>> int main() {
>>> return 10 + foo();
>>> }
>>> --- end backtrace.c ------------
>>>
>>> If we grab stack frames by instrumenting the function directly --
>>> "pid$target::atomic_swap_32:entry {...@counts[ustack()]=count();}" -- then
>>> we get:
>>>
>>> libc.so.1`atomic_swap_32
>>> a.out`foo+0x2c
>>> a.out`main+0x4
>>> a.out`_start+0x108
>>> 1054138
>>>
>>> If, on the other hand, we profile the process --
>>> "profile-7777us/pid==$target/ {...@counts[ustack()]=count(); }" -- and grab
>>> stack frames again, we get (among other far rarer variants):
>>>
>>> libc.so.1`atomic_swap_32
>>> a.out`main+0x4
>>> a.out`_start+0x108
>>> 1167
>>>
>>> Note that this is *not* related to tail calls (there are none here). Since
>>> in both cases $pc is the same, the problem must be due to either the
>>> profile probe's way of saving process context or else the stack walking
>>> code doing something wrong under profiling...
>>>
>>> Ideas?
>>> Ryan
>>>
>>> _______________________________________________
>>> dtrace-discuss mailing list
>>> dtrace-discuss@opensolaris.org
>>>
>>
>> --
>> Adam Leventhal, Fishworks http://blogs.sun.com/ahl
>>
>>
>
> <profile-i7.d><profile-i7.awk>
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
