This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Fwd: Re: Regarding systemtap support for AArch64]
- From: Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>
- To: William Cohen <wcohen at redhat dot com>
- Cc: Petr Machata <pmachata at redhat dot com>, Mark Wielaard <mjw at redhat dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, systemtap at sourceware dot org, Deepak Saxena <dsaxena at linaro dot org>, Krishna Dani <krishna dot mohan at linaro dot org>, Jakub Pavelek <jakub dot pavelek at linaro dot org>, Mark Salter <msalter at redhat dot com>
- Date: Fri, 8 Nov 2013 07:52:02 +0530
- Subject: Re: [Fwd: Re: Regarding systemtap support for AArch64]
- Authentication-results: sourceware.org; auth=none
- References: <1383340682 dot 3850 dot 864 dot camel at bordewijk dot wildebeest dot org> <m2habsnq4w dot fsf at redhat dot com> <5277FBF2 dot 2080108 at redhat dot com> <m2wqknmumc dot fsf at redhat dot com> <52791818 dot 9070809 at redhat dot com> <m2eh6tn9cv dot fsf at redhat dot com> <CA+b37P2xA5vDBW7rWrEfTOvrzCC+VQpjad+Ge26m6uRjG-sp2w at mail dot gmail dot com> <527BAA13 dot 4000301 at redhat dot com>
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