[Ltrace-devel] ARM support

[Petr Machata]

Florian Echtler <floe at butterbrot.org> writes:

> On the pro side: no spurious crashes anymore. I'm assuming this was
> indeed a multi-threading issue.
>
> However, on the con side: no library calls are traced anymore either.
> (Syscalls still work fine). As before, my command line is:

If you see no calls, that most probably means breakpoints are either not
inserted at all, ar inserted to wrong addresses (as you indicate below).
Therefore nothing hits them, and things keep working (unless the
breakpoint happens to maim some important datum somewhere).  Absence of
failures is a natural consequence of absence of tracing.

> ./ltrace -F ltrace.conf -f -p 556 -D 77 \
>   -x open -x close -x read -x write
>
> Excerpt from the debug log:
>
> DEBUG: breakpoint.c:43: enable_breakpoint: pid=556, addr=0xafc0b450,
> symbol=read
> DEBUG: breakpoint.c:35: arch_enable_breakpoint(556,0xafc0b450)
> DEBUG: breakpoint.c:46: current = 0xffffffff, orig_value = 0x0,
> thumb_mode = 0
>
> DEBUG: breakpoint.c:43: enable_breakpoint: pid=556, addr=0x8a00,
> symbol=_ZNK7android7RefBase9decStrongEPKv
> DEBUG: breakpoint.c:35: arch_enable_breakpoint(556,0x8a00)
> DEBUG: breakpoint.c:46: current = 0xe28fc600, orig_value = 0x0,
> thumb_mode = 0
>
> Note the difference between the externally specified function (read)
> where current = 0xffffffff and the auto-added function where current !=
> 0xffffffff.

current=-1 seems to indicate that PTRACE_PEEKTEXT failed.  Unfortunately
ltrace is full of unchecked errors.  Here this is apparently caused by
reading from unmapped region (wrong address).  Since these are requested
by -x, it seems that _r_debug probe at least found the list of libraries
and went over them, trying to add breakpoints.

> /proc/556/maps shows:
>
> 00008000-00009000 r-xp 00000000 1f:00 459        /system/bin/app_process
> 00009000-0000a000 rwxp 00001000 1f:00 459        /system/bin/app_process
> 0000a000-0065d000 rwxp 0000a000 00:00 0          [heap]
>
> [This looks correct to me: the 0x8a00 address is somewhere within the
> original process.]
>
> afc00000-afc01000 r-xp 00000000 1f:00 411        /sys../lib/libstdc++.so
> afc01000-afc02000 rwxp 00001000 1f:00 411        /sys../lib/libstdc++.so
> afd00000-afd40000 r-xp 00000000 1f:00 401        /system/lib/libc.so
> afd40000-afd43000 rwxp 00040000 1f:00 401        /system/lib/libc.so
>
> [This looks wrong: address 0xafc0b450 is somewhere between the spaces
> where libstdc++.so and libc.so have been mapped...]

This is puzzling.  It's as if it took symbols from libc.so and applied
them on top of libstdc++.  Strange.

> Looking at /system/lib/libc.so with readelf -a shows:
>
>    109: 0000b450     0 FUNC    GLOBAL DEFAULT    7 read
>
> Apparently, the offset is correct, but the base address is wrong.
>
> I have a hunch this is somehow - again - caused by the
> weird/strange/broken linker from Android's bionic-libc; I will
> investigate.

I just tried ltrace on trimslice (Ubuntu 10.10), and it seems to be more
or less working.  The testsuite is not remotely clean, and I'm seeing
spurious SIGILLs (I suspect most failures are due to this), but it's not
as bad as I had expected after some reports on this list.  Both ARM and
Thumb binaries seem to be approximately on par.  Even threading seems OK
(if you are lucky and none of the threads SIGILL's).

The situation is similar with the libs branch that I'd like to merge
soonish, though the compilation needs some ironing out (a couple
includes are missing here and there).  So there are bugs in ARM support,
but it's not catastrophic and it works "a bit".

So... yeah, it seems like it's something in Android rubbing ltrace the
wrong way.

Thanks,
PM