Systemtap on ARM arch results summary

[David Long]

On 06/16/14 15:04, William Cohen wrote:
> On 06/13/2014 02:13 PM, David Long wrote:
>> On 06/12/14 11:42, William Cohen wrote:
>>> On 06/12/2014 11:18 AM, David Long wrote:
>>
>>> 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.
>>>
>>
>> William,
>>
>> I assume then that the C runtime library is also built without thumb instructions?  I think a thumb C library is causing a lot of my troubles, especially when tests do a process probe of ("*").
>
> On Fedora nothing is built with thumb/thumb2 code. It seems like systemtap should be checking to see if the executable is thumb/thumb2 code and not try to instrument it if that is the case.
>>
>> I assume you're testing with uprobes, now that the feature is available in the ARM kernel?  If so note there's a patch to cache flushing inside uprobes from Victor Kaminsky that went into the v3.16 merge window, and which is important (it fixes that intermittent at_var segv you first reported 8 months ago).
>
> Yes, the kernel on that arm machine is being built with uprobe support.  The tests were with the 3.15 kernel and didn't have the 3.16 patch you mention.  I will be build a new kernel with that patch.
>>
>> I'm curious to see the (compressed) systemtap.log from one of your more recent runs.  It would help me determine which failures might be real uprobes issues.
>
> Attached is the systemtap.sum.gz from last thursday.
>
> -Will
>


I do have thumb mode uprobes nominally working, although a couple 
[horrible] hacks in it need to be cleaned up before sending the patch to 
upstream.  So theoretically I could test thumb uprobes in systemtap if 
systemtap can detect that it's a thumb instruction being probed and then 
set the low-bit of the address for the probe (the kernel has no way of 
deciding on its own that a uprobe is for thumb or ARM mode).

-dl