Re: Systemtap on ARM arch results summary

[William Cohen <wcohen at redhat dot com>]

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.

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?

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

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

-Will