This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Systemtap on ARM arch results summary


On 06/17/14 10:07, William Cohen wrote:
On 06/16/2014 03:14 PM, David Long wrote:
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


Hi David,

So the problem is the static determination that that code is thumb code.  When the process is running there some information in the status bits to indicate whether the processor is in in thumb mode. However, for a given address uprobes doesn't have need information to know which instruction to insert. There are different instruction encodings used for arm32 and thumb software interrupts ('n' hex place holder):

arm 32-bit:   0xnfnnnnnn
thumb 16-bit: 0xdfnn


-Will


Yes, that does summarize the problem. An analysis tool that can look at the executable file might be able to determine if an instruction is in a section of thumb or ARM code (I'm not completely sure on this point), but not by just looking in the application address space in memory. As you stated, we can't use the CPSR bits for this because we obviously need to put the breakpoint in before we get to it.

-dl


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]