This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fwd: Re: Regarding systemtap support for AArch64]


On 7 November 2013 20:26, William Cohen <wcohen@redhat.com> wrote:
> On 11/07/2013 06:54 AM, Sandeepa Prabhu wrote:
>> On 6 November 2013 15:24, Petr Machata <pmachata@redhat.com> wrote:
>>> William Cohen <wcohen@redhat.com> writes:
>>>
>>>> On 11/04/2013 09:48 PM, Petr Machata wrote:
>>>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that
>>>>> got us here.  So possibly makes sense.  0x112 is __NR_syscalls, I don't
>>>>> see how that ended up there.  Maybe from a conditional?  0x2004 might
>>>>> certainly be a length, though it's an odd one.  The two kernel-space
>>>>> parameters have similar values, and the one user-space is quite
>>>>> different--again, makes sense.
>>>>
>>>> These examples systemtap might not be the best.  It is just printing
>>>> information for the first vfs.read or vfs.read.return encountered, so
>>>
>>> I understand.  I was trying to figue out what's in the registers.  I can
>>> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on
>>> function return, x0 hold the return value?
>>>
>>>> I wonder if there might be some issue with the patches implementing
>>>> the arm64 kprobes support and that the registers are not be saved
>>>> properly.
>>>
>>> I was wondering about the same thing.
>> Hi Will, Petr,
>>
>> Yes, I found some design issue with respect to trampoline placement,
>> (my code is the culprit!!). I am going to fix this soon and update you
>> all.
>>
>> Thanks,
>> Sandeepa
>>>
>>> Thanks,
>>> PM
>
> Hi Sandeepa,
>
> I was just going to ask you about the trampoline code.  I ran a little experiment and it looked like the place the probe was firing wasn't correct.
>
> $ sudo ~/systemtap_write/install/bin/stap  -k -v -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
> [sudo] password for wcohen:
> Pass 1: parsed user script and 93 library script(s) using 140720virt/25044res/2776shr/22936data kb, in 4740usr/190sys/5353real ms.
> Pass 2: analyzed script: 2 probe(s), 8 function(s), 6 embed(s), 0 global(s) using 323612virt/103604res/3656shr/100456data kb, in 39780usr/13630sys/58215real ms.
> Pass 3: translated to C into "/tmp/stap0GjZue/stap_1107_src.c" using 323612virt/105948res/6000shr/100456data kb, in 150usr/10sys/176real ms.
> Pass 4: compiled C into "stap_1107.ko" in 119270usr/10570sys/143518real ms.
> Pass 5: starting run.
> $return = 0xffffffc04609f700
> pc : [<ffffffc000186134>] lr : [<ffffffc000186924>] pstate: 60000145
> sp : ffffffc04ce8be30
> x29: ffffffc04ce8be80 x28: ffffffc04ce88000
> x27: ffffffc000835000 x26: 000000000000003f
> x25: 0000000000000112 x24: 0000000000000015
> x23: 0000000080000000 x22: 0000007f7a332aa8
> x21: 0000000000000001 x20: 0000007fd0e51730
> x19: ffffffc04609f700 x18: 0000007fd0e4f250
> x17: 0000007f7a332a50 x16: ffffffc0001868e0
> x15: 0000000000000004 x14: 0000007fd0e53a70
> x13: 0000000000000001 x12: 0000000000000000
> x11: 0000007fd0e4f530 x10: 0000000000401277
> x9 : 0000000000000028 x8 : 000000000000003f
> x7 : 0000000000000005 x6 : 0000000000000000
> x5 : 0000000000000002 x4 : 0000000000000000
> x3 : ffffffc04ce8beb0 x2 : 0000000000002004
> x1 : 0000007fd0e51730 x0 : ffffffc04609f700
>
> Pass 5: run completed in 120usr/80sys/579real ms.
> Keeping temporary directory "/tmp/stap0GjZue"
> [wcohen@localhost systemtap]$
>
>
> Look at pc : [<ffffffc000186134>]
>
> ffffffc000186130 <vfs_read>:
> ffffffc000186130:       a9bb7bfd        stp     x29, x30, [sp,#-80]!
> ffffffc000186134:       910003fd        mov     x29, sp
> ffffffc000186138:       a9025bf5        stp     x21, x22, [sp,#32]
> ffffffc00018613c:       a90153f3        stp     x19, x20, [sp,#16]
>
>
> Look at  lr : [<ffffffc000186924>]
>
> ffffffc00018691c:       f9001ba4        str     x4, [x29,#48]
> ffffffc000186920:       97fffe04        bl      ffffffc000186130 <vfs_read>
> ffffffc000186924:       aa0003f4        mov     x20, x0
>
> The lr value look plausible, but the pc value looks like the function entry not the function exit.
Yes exactly, the trampoline was replacing exception return (ERET)
address not the function return (RET) address! (wrong manipulation of
saved pt_regs), so was firing ret-probe at the function entry not
return and x0 showed the function argument not the return value.
Thanks for pointing out this, have fixed this on my devel branch.
~Sandeepa
>
> -Will


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]