[Ltrace-devel] ARM support

[Petr Machata]

Florian Echtler <floe at butterbrot.org> writes:

> On 25.04.2012 14:58, Petr Machata wrote:
>> But in fact clone support was in for a long time now, maybe try to pass
>> -f on the command line.  The tracing might still fail, calls and returns
>> might get missed across threads, but chances are it will work a bit
>> better.
> I've given "-f" a try - no success, unfortunately.
>
> Here's the commandline I'm using:
>
> ltrace -f -x open -x close -x read -x write -x socket \
>        -F ltrace.conf -p 405

Ah, that wouldn't work with 0.6.0.  -f is for following clones and
forks, it doesn't know that it should attach to all tasks of a running
process (master does though).  That also explains there are no clones
visible: they already happened before you attached.  You might check
/proc/pid/task, there'll be one directory per thread.  If there's more
than one, you've got yourself a multi-threaded app, and 0.6.0 will break
that.

> I forgot to mention one peculiar aspect: I explicitly have to add the
> system functions I'm interested in via "-x func", otherwise, they will
> not be traced. I assume that is due to the way the Android linker loads
> libraries into Dalvik processes (shell tools, again, work fine without
> this kludge).

That's probably because it dlopens the libraries.  We have a hack on
master where ltrace looks for -x symbols in dlopened libraries, if it
doesn't find them in the main binary.  This should all go away with the
code on libs branch, where ltrace applies the selected filtering rules
to all mapped-in DSOs (and the main binary).

> Also, the crash doesn't happen immediately, usually only when triggering
> a complex UI interaction (e.g., opening a new view). The more functions
> I'm tracing, the sooner the crash happens - so I'm starting to assume
> some kind of race condition.
>
> However, if I omit the -x switches for libc functions (and only add very
> specific functions, e.g. from package-owned libraries), then everything
> works: I see the traced functions being called, and no crash.
> (This may actually be the same issue than mentioned above: less
> breakpoints, less chance of race condition).

Yep, that's what I think is causing that.

>> That's on master as well.  There's about 60 commits on top of what's
>> tagged 0.6.0, and most of that is for fixes relating to tracing
>> processes with shared address space.  We should really do 0.7, but I
>> can't seem to be able to reach Juan.
> In any case, I'll forward-port my patch to master and see if there's any
> difference.

Be sure to post your findings.

Thanks,
PM