RE: wrong calculation of kprobe.addr?

[Guang Lei Li <liguangl at cn dot ibm dot com>]

> >Bibo,mao ---->
> > About kprobe probe point it is function prologue end point, and 
> > about kprobe return point it is function entry point. You can use 
> > "objdump -DS" command get function assembly and c source mixed file.
> > And then you can compare this two different probe point.
> > 
> 
> 
> > >Guanglei --->
> > >From dumpedFile
> > >c02402e0 <elv_next_request>:
> > >c02402e0:       push   %edi
> > >c02402e1:       push   %esi
> > >c02402e2:       mov    %eax,%esi
> > >c02402e4:       push   %ebx
> > >c02402e5:       sub    $0xc,%esp
> > >c02402e8:       jmp    c0240309 <elv_next_request+0x29>
> > >c02402ea:       lea    0x0(%esi),%esi
> > >c02402f0:       orl    $0x2000,0x8(%ebx)
> > >c02402f7:       mov    %edi,%ecx
> > >
> 
> The function prologue should be before 0xc02402e8. But you see that 
> systemtap use 0xc02402f0 as the function prologue end point, which I 
think 
> is wrong.
> 
> I wrote a kernel module to register kprobe handler directly. I set the 
> kprobe.addr=0xc02402f0, then the kprobe handler will never be executed. 
If 
> I set the kprobe.addr to 0xc02402e8, 0xc02402e5, 0xc02402e2 etc( between 

> c02402e0 and c02402e8), the kprobe handler will be executed.
> 
> It seems that systemTap use elfutils to calculate the function prologue 
> end point, so is it a bug of elfutils?
> 
> 
Today I met another problem which seems also related with registering 
kprobe at wrong address

I applied the patch from #1345 to 2.6.9-22.17. It worked, my Power5 won't 
crash any more.

But I found another problem. I probed all syscalls entry&return, but for 
sys_fadvise64, I can only got report of entering into this function, and 
no returning is caught.

After looked at the sys_fadvise64, I think at least for 32-bit app this 
function shouldn't be called on Power5.

Then I tried to found what happened

Disassembly of section .text:

c00000000009437c <.sys_fadvise64>:
c00000000009437c:      c00000000009415c <.sys_fadvise64_64>

c000000000094380 <.bad_range>:
c000000000094380:       std     r30,-16(r1)
c000000000094384:       ld      r30,-11712(r2)
c000000000094388:       mr      r6,r3
c00000000009438c:       lis     r9,28086


This is the address that systemTap used to register the handler of 
sys_fadvise64:
static struct kprobe dwarf_kprobe_0[1]= {
  {.addr= (void *) 0xc000000000094380}
};

It's obvious that the address is wrong. Here's another example of 
sys_send:

static struct kprobe dwarf_kprobe_0[1]= {
  {.addr= (void *) 0xc00000000026a0dc}
};

c00000000026a0d0 <.sys_send>:
c00000000026a0d0:       li      r7,0
c00000000026a0d4:       li      r8,0
c00000000026a0d8:       b       c000000000269fb8 <.sys_sendto>

c00000000026a0dc <.sys_recvfrom>:
c00000000026a0dc:       mflr    r0
c00000000026a0e0:       std     r24,-64(r1)

It seems to me that if a function is in the format of:
  function(...)
  {
     ...
     return another_function(..)
  }
 then it's easier for systemTap to calculate the wrong address for 
register kprobe handler.