[Ltrace-devel] ARM support

[Florian Echtler]

On 25.04.2012 11:39, Petr Machata wrote:
> Florian Echtler <floe at butterbrot.org> writes:
>> [...]
>> read(37, "D", 1)                                 = 1
>> write(38, "f", 1)                                = 1
>> +++ killed by SIGTRAP +++
>>
>> Is this a known problem? My Android patch mostly fixed a few function
>> signatures and build issues, so I'm unsure whether it is the culprit...
>> [ For reference, it is available at https://github.com/floe/ltrace ].
> I looked into your patch set.  First, I was using error.h liberally in
> my code, as I thought it's standard, but apparently it isn't.  Mea
> culpa, I'll need to fix that before merging.  Other than that, I don't
> see anything in your patches that would break tracing like what you
> show.
Alright, thanks for your quick response. Good to know.

> If you forked off 0.6.0, the threading fixes aren't in yet.  Might that
> be the cause?  I don't see any evidence of threads in your snippet, but
> if the process that you are tracing shares the address space with
> someone else, that someone else will see breakpoints that ltrace puts
> in, and will be SIGTRAP'd if it hits one of those.  That would then kill
> the original traced process as well, which is what you are seeing.
That sounds very plausible; this issue only appears when tracing
full-blown Dalvik VM processes and not with regular shell tools. I'm not
quite sure about the details, but Dalvik definitely uses some shared
memory magic for faster startup, so this might be the cause.

Which branch is the one with threading fixes, I'm assuming pmachata/libs?

> There's a bunch of patches that implement support for processes with
> shared address space.  Unfortunately those same patches might break ARM
> support.  They also rely on procfs, is that available on Android?
Yes, procfs is available. Are these patches also in one of your branches?

> Other than that I don't know what might cause that ltrace interprets
> SIGTRAP as a real signal as opposed to a tracing event.  Maybe if
> Android kernel doesn't support PTRACE_O_TRACESYSGOOD we might be hitting
> some weird corner case (that's not really tested, recent kernels all
> know about that option).
The Android version I'm using (2.3.3) has kernel 2.6.29, so AFAICT that
shouldn't be a problem.

Florian
-- 
SENT FROM MY PDP-11