dtrace discuss - Dec 2007 - why was some stack information lost.

I wrote a simple c programme and do some dtrace test. the progromme shows
below(write.c):
///////////////////////////////
#include<stdio.h>
     #include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
char *value="hello,my name is wanjm\n"; 
void main()
{
int fd;
fd=open("/export/home/wanjm/temp/read.txt",O_RDWR|O_CREAT);
while(1)
{
        sleep(1);
        write(fd,value,strlen(value));
}
}

////////////////////////////////////////
and the dtrace script (write.d) is:
syscall::write:entry,
fbt::write:entry,
pid$1::write:entry,
pid$1::write:return,
pid$1::_write:entry
/pid==$1/
{
printf("%s:%s:%s:%s\n",probeprov,probemod,probefunc,probename);
stack(100);
ustack(100);
}
///////////////////////////////
when runs the script, the result is :
pid17632:libc.so.1:write:entry
              libc.so.1`write
              a.out`main+0x43
              a.out`_start+0x7a
pid17632:libc.so.1:_write:entry
[b]              libc.so.1`_write
              [u]libc.so.1`write+0x75[/u][/b]
              a.out`main+0x43
              a.out`_start+0x7a
syscall::write:entry
              unix`sys_sysenter+0x101

[b]              libc.so.1`_write+0x15
              a.out`main+0x43[/b]
              a.out`_start+0x7a
fbt:genunix:write:entry
              genunix`dtrace_systrace_syscall+0xb9
              unix`sys_sysenter+0x101
              libc.so.1`_write+0x15
              [u]a.out`main+0x43[/u]
              a.out`_start+0x7a
pid17632:libc.so.1:write:return
              libc.so.1`write+0x90
              a.out`_start+0x7a

when syscall probe fires ,why  does the stack information lost
[u]libc.so.1`write+0x75[/u]
and when pid17632:libc.so.1:write:return fires?the main function was lost me.

could you please me the reason.


--
This message posted from opensolaris.org

On Fri, Dec 28, 2007 at 07:10:26PM -0800, wan_jm wrote:
> when syscall probe fires, why does the stack information lost
[u]libc.so.1`write+0x75[/u]
In _write, we don''t push a stack frame:

libc.so.1`_write:               movl   $0x4,%eax
libc.so.1`_write+5:             syscall 
libc.so.1`_write+7:             jae    +0xa     <libc.so.1`_write+0x13>
libc.so.1`_write+9:             cmpl   $0x5b,%eax
libc.so.1`_write+0xc:           je     -0xe     <libc.so.1`_write>
libc.so.1`_write+0xe:           jmp    -0x81df3 <libc.so.1`__cerror>
libc.so.1`_write+0x13:          ret    

Because of this, a stack trace will omit what is logically the previous frame
-- in effect, _write is executing out of write''s frame. We catch this
in
pid provider entry probes because of a specific hack to account for the fact
that at the entry probe the function won''t have pushed a new stack
frame. We
don''t have the necessarily semantic information from the syscall probe
at
to do something similar.
> and when pid17632:libc.so.1:write:return fires?the main function was lost
me.
This is a filed bug:

  6551219 ustack from pid return probe omits previous frame

We''re implement a hack similar to what we do for pid provider entry
probes.

- ahl

-- 
Adam Leventhal, FishWorks                        http://blogs.sun.com/ahl