This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]