RE: wrong calculation of kprobe.addr?

["Mao, Bibo" <bibo dot mao at intel dot com>]

Systemtap tool has some problem when get function prologue end address, if you run command "./find-prologues  -k" in elfutils-0.116/tests/ directory, you will find that function prologue end address is different from what is generated by systemtap script translater.

Regards
Bibo,mao

>-----Original Message-----
>From: Guang Lei Li [mailto:liguangl@cn.ibm.com]
>Sent: 2005年11月25日 21:09
>To: systemtap@sources.redhat.com
>Cc: Mao, Bibo; hien@us.ibm.com; roland@redhat.com
>Subject: RE: wrong calculation of kprobe.addr?
>
>> >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.