[Ltrace-devel] ARM support

Petr Machata pmachata at redhat.com
Wed Apr 25 09:39:03 UTC 2012


Florian Echtler <floe at butterbrot.org> writes:

> [...]
> read(37, "D", 1)                                 = 1
> write(26, "W", 1)                                = 1
> write(38, "f", 1)                                = 1
> read(25, "W", 16)                                = 1
> 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.

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.
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?

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).

Thanks,
PM



More information about the Ltrace-devel mailing list