What is wrong with dtrace's stack()?

[Lev Serebryakov]

Hello Freebsd-hackers,

 I'm trying to profile strange if_gif and if_gre performance on hardware
without pmc. So, I'm sampling kernel stacks with simple dtrace script.

 And I have a lot of stacks which show something like this:

  kernel`ipsec_hdrsiz_inpcb+0xa1
  kernel`soo_write+0x33
  kernel`dofilewrite+0x79
  kernel`sys_write+0xc3
  kernel`amd64_syscall+0x332
  kernel`0xffffffff8086c87d

 Functions after soo_write could be different, but address is always the
same: soo_write+0x33.

 But soo_write doesn't call all these functions, in first place! soo_write
looks like:

Dump of assembler code for function soo_write:
   0xffffffff8060f930 <+0>:     push   %rbp
   0xffffffff8060f931 <+1>:     mov    %rsp,%rbp
   0xffffffff8060f934 <+4>:     push   %r15
   0xffffffff8060f936 <+6>:     push   %r14
   0xffffffff8060f938 <+8>:     push   %r12
   0xffffffff8060f93a <+10>:    push   %rbx
   0xffffffff8060f93b <+11>:    sub    $0x10,%rsp
   0xffffffff8060f93f <+15>:    mov    %rsi,%r12
   0xffffffff8060f942 <+18>:    mov    (%rdi),%rbx
   0xffffffff8060f945 <+21>:    mov    0x28(%r12),%rax
   0xffffffff8060f94a <+26>:    mov    %rax,(%rsp)
   0xffffffff8060f94e <+30>:    xor    %esi,%esi
   0xffffffff8060f950 <+32>:    xor    %ecx,%ecx
   0xffffffff8060f952 <+34>:    xor    %r8d,%r8d
....

 Now I can not trust all these collected stacks. What do I do wrong?!

I have in my kernel config:

makeoptions     DEBUG=-g
makeoptions     WITH_CTF=1              # Run ctfconvert(1) for DTrace support
options         KDTRACE_FRAME           # Ensure frames are compiled in
options         KDTRACE_HOOKS           # Kernel DTrace hooks

-- 
Best regards,
 Lev                          mailto:lev at FreeBSD.org