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: William Cohen <wcohen at redhat dot com>
- To: Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>, Petr Machata <pmachata at redhat dot com>
- Cc: 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: Thu, 07 Nov 2013 09:56:19 -0500
- 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>
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