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
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
