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: Petr Machata <pmachata at redhat dot com>
- To: William Cohen <wcohen 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: Tue, 05 Nov 2013 03:48:27 +0100
- 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>
William Cohen <wcohen@redhat.com> writes:
> x0 : FFFFFFC04ABE5E00 0000007FCC574070 0000000000002004 FFFFFFC077CFBEB0
> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FCC571E70
> x12: 0000000000000000 0000000000000001 0000007FCC5763B0 0000000000000004
> x16: FFFFFFC0001868E0 0000007FA3F26A50 0000007FCC571B90 FFFFFFC04ABE5E00
> x20: 0000007FCC574070 0000000000000001 0000007FA3F26AA8 0000000080000000
> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
> x28: FFFFFFC077CF8000 FFFFFFC077CFBE80 FFFFFFC000186924
> sp [ffffffc077cfbe30] pc [ffffffc000186134]
> pstate [0000000060000145]
> orig_x0 [0000000000000015]
> syscallno [0000000000000112]
> Keeping temporary directory "/tmp/stap1OWdNi"
>
> $ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read {printf("$$parms = %sn", $$parms);print_regs(); exit()}'
> [sudo] password for wcohen:
> $$parms = file=0xffffffc04ab83e00 buf=0x7fdaad4290 count=0x2004 pos=0xffffffc043847eb0n CPU: 0
> x0 : FFFFFFC04AB83E00 0000007FDAAD4290 0000000000002004 FFFFFFC043847EB0
> x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
> x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FDAAD2090
> x12: 0000000000000000 0000000000000001 0000007FDAAD65D0 0000000000000004
> x16: FFFFFFC0001868E0 0000007F7F6E0A50 0000007FDAAD1DB0 FFFFFFC04AB83E00
> x20: 0000007FDAAD4290 0000000000000001 0000007F7F6E0AA8 0000000080000000
> x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
> x28: FFFFFFC043844000 FFFFFFC043847E80 FFFFFFC000186924
> sp [ffffffc043847e80] pc [ffffffc000186130]
> pstate [0000000060000145]
> orig_x0 [0000007fdaad4120]
> syscallno [ffffffc000082fec]
> Keeping temporary directory "/tmp/stapQI9d6o"
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.
So why doesn't the return value appear in x0 I don't understand. Is the
0x15 in orig_X0 the right return value?
Thanks,
PM