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

[William Cohen <wcohen at redhat dot com>]

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.

-Will