Re: aarch64 systemtap testsuite results

[Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>]

On 14 May 2014 14:44, Martin Cermak <mcermak@redhat.com> wrote:
> Hi Jakub,
>
> At the moment, I believe, the most important issue is correct kprobes support, tracked as bug 1074123 in Red Hat bugzilla. Important points:
>
>> There are two issues:
>> (1) kprobes needs a 'blacklist' of kernel functions that can't be probed, b/c kprobe uses them -- infinite loop.  upstream has a V10 of a 7-patch series for this, so hopefully its close for us to use in near term.
Those patches are close to upstream, and expect  changes in arm64
(arch code) kprobes code as well to adapt these.

>> (2) Linaro kprobe developer agrees there is a bug in the multi-kprobe implementation.  I have hooked him up w/Will Cohen to get systemtap sources to use for their duplication, then debug & test efforts.
Yes, mainly since the failure summary reported hang while probing
read* syscalls, and I suppose none of the read system calls should be
in blacklist! as those calls wouldn't be invoked from kprobes or debug
exceptions. So I suspect a bug in my kprobes implementation, even
though I had tested for multi- and recursive probes on models, I have
not covered exhaustive tests like systemtap on real hw.

I am working with Will and Don on another e-mail thread, hope to
root-cause the issue sometimes soon :-)

Cheers,
~Sandeepa
>
> It'd be great to move on with this.
>
> Kind Regards,
> Martin
>
> ----- Original Message -----
>> Hello William,
>>
>> many thanks for the update!
>>
>> Is any of the reported issues something that Linaro should work on fixing?
>> Here at Linaro we want to get Systemtap running in our automated testing
>> loop for ARMv8 and we hope to fare better in pass-rates as we have ARM64
>> kprobes implementation included in Linaro kernel already.
>>
>>
>> On 7 May 2014 16:15, William Cohen <wcohen@redhat.com> wrote:
>>
>> > Some actual aarch64 hardware is now available and the testsuite can be run
>> > in a ressonable amount of time. The test results show signs of life, but
>> > there is definitely room for improvement:
>> >
>> >
>> > https://web.elastic.org/~dejazilla/viewsummary.php?variant=%3D%27aarch64-unknown-linux-gnu%27
>> >
>> > There are going to be a lot of failures in these tests because the kernel
>> > did not have kprobe patches in it. There is also no uprobes support in the
>> > kernel.
>> >
>> > Some other things observed when reviewing the results:
>> >
>> > -a number of tests failed to build because of missing kernel header
>> > hypervisor.h. The kernel-devel rpm appeared to omit some needed header
>> > files
>> >
>> > -tracepoints probe locations did not work.  The probe points are visible
>> > in "perf list" but "stap -L 'kernel.trace("*")'" returns nothing.
>> >
>> > -aarch64 stack backtraces are not yet supported.
>> >
>> > -Can't find  @cast(sock, "inet_sock", "kernel<net/ip.h>") for
>> >  stap -v ./systemtap.base/ipaddr1.stp
>> >
>> > -The preprocessor sets arch to "arm64" rather than "aarch64" "preprocessor
>> > basic ops" fails
>> >
>> > -The nd_syscall probes points are not available
>> >
>> > -SystemTap could not find locations of $prev or $next arguments for
>> > kernel.function("context_switch")
>> >
>> >
>> >
>> >
>> > -Will
>> >
>>
>>
>>
>> --
>> With best regards,
>>
>> Jakub Pavelek
>>
>> Kernel working group and Android engineering project manager
>> Linaro.orgâ Open source software for ARM SoCs
>>