Re: Systemtap on ARM arch results summary

[David Long <dave dot long at linaro dot org>]

On 06/12/14 11:42, William Cohen wrote:
> On 06/12/2014 11:18 AM, David Long wrote:
> > On 06/12/14 11:05, William Cohen wrote:
> >
> > > Hi Naresh,
> > >
> > > Glad to hear that you got the tests up and running.  You mentioned that this a self hosted build of the kernel. It is pretty easy to compare the various armv7 testsuite runs on:
> > >
> > >    https://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=20&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnueabihf%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
> > >
> > > I noticed there are some additional failure in your testsuite run.  335 vs 94.  Do you have uprobes turned on for the kernel?
> > >
> > > https://web.elastic.org/~dejazilla/viewrgdiff.php?rg1=382655&rg2=964991&_offset=0&_limit=10000&_offset=0&testcase=&r1=&r2=
> > >
> > >
> > > However, it looks like the tests on my arm chromebook were abbreviated due to a tcl error during the syscall.exp test, resulting in fewer total passes.
> > >
> > > -Will
> >
> >
> > Hi William,
> >
> > There's several tests I had to disable in this run to prevent hangs. The more severe change is that I had to modify the *.exp files and the systemtap build to use "gcc -marm", as uprobes currently does not work for thumb and thumb is the default in the compiler.  Does your compiler default to generating ARM instructions, or how else did you overcome this problem for uprobes testing?
> >
> > -dl
>
> Hi David,
>
> Fedora on ARM sets the gcc compiler to "-march=armv7-a", so it is not generating thumb/thumb2 instructions.  I guess that makes it easier for Fedora.

I strongly suspect some of the remaining uprobes-related failures come 
from system thumb library/startup code that gets probed.

> Were the hangs exclusively due to uprobes attempting to probe user-space thumb code or is this a problem with the code that systemtap is generating as a module?

One was a kernel hang, the others were interruptable hangs. I did not 
investigate further.  I disabled the tests by deleting the stp and exp 
files for:

systemtap.base/poll_map
systemtap.base/pr10854
systemtap.base/pr14546
systemtap.base/probefunc
systemtap.base/target_set_thread systemtap.unprivileged/unprivileged_myproc

It looks like most of those don't use uprobes.

> Do you have a patch set showing where you needed to make changes to the *.exp files?

I have something, but it is a total hack.  I just hardcoded the -marm 
where needed, for a quick test.  My plan is to go back and make that 
conditional on the target type.  This does bring up an interesting point 
though.  I didn't see an obvious way to pass global compiler options 
into the test cases.  That would have been very helpful.  At any rate I 
think some global mechanism is needed to deal with CPUs that support 
multiple instruction sets.  Eventually we'd want to run systemtap 
multiple times on a given platform, to test thumb, thumb2, ARM, and/or 
64bit.  Maybe other more specific code generation options too.

> Out of curiosity how much of a difference do the thumb code make on the size of the executable?

I haven't collected numbers on that.  Looking at the stap binary the 
sizes are 23828508 and 23337084.  So that's a pretty small difference. 
I'm sure there's much more info out on the web about this.

-dl