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

[William Cohen <wcohen at redhat dot com>]

On 11/07/2013 08:49 AM, Sandeepa Prabhu wrote:
> On 7 November 2013 19:13, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>> On 7 November 2013 17:24, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> 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.
>>>
>> Hi Will, Petr,
>>
>> I have fixed the issue and now able to get proper function return
>> values. (Earlier, trampoline was not installed at correct location, so
>> used to carry wrong register context to handler)
>> Updated patches are at:
>> https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-devel
>>
>> Please switch to my devel branch:
>> "git://git.linaro.org/people/sandeepa.prabhu/linux-aarch64.git
>> Branch: arm64-kprobes-devel"     and let me know how this work.
> [ Also, please ignore the code comment and commit descriptions, I will
> change them when publishing v3 patchset, but before that, want to
> conduct more test and find as many bugs as possible ]

Hi Sandeepa,

I have switched to the arm64-kprobes-devel branch, pulled in the msalters uefi patches (armv8-uefi-lates branch of https://github.com/mosalter/linux), and started building a new kernel. The simulator is slow, so it will take a while for a new kernel to be available.

I have pushed the aarch64 print_reg() support into the systemtap git repository to make it easier to test out aarch64 support include the kprobes and kretprobes.  So on the aarch64 simulator something like the following to get a systemtap that has support for aarch64:

# get the elfutils sources
cd ~
git clone git://git.fedorahosted.org/git/elfutils.git
cd elfutils
git checkout aarch64
# get systemtap
cd ~
mkdir systemtap_write
cd systemtap_write
git clone git://sourceware.org/git/systemtap.git
cd systemtap
./configure --disable-docs --prefix=~/systemtap_write/install --with-elfutils=~/elfutils
make
make install

I noticed for the 32-bit arm uprobes that there are some test to make sure that the uprobes simulate the instructions properly.  How are the various instructions emulation/fixups for the arm64 being tested?  The code for the 32-bit arm uprobes testing is at:

https://github.com/rabinv/uprobes-test


-Will