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: Wed, 06 Nov 2013 10:54:40 +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> <m2wqknmumc dot fsf at redhat dot com> <52791818 dot 9070809 at redhat dot com>
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.
Thanks,
PM