[Ltrace-devel] ARM support

[Florian Echtler]

Hello again,

On 25.04.2012 19:23, Petr Machata wrote:
>>> 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.
[Warning: long post to follow]

I've ported my patch to master, see also repo at [1].

Results:

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:

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


/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...]


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.


Nevertheless, I would be very grateful for any additional insights on
what might have changed between 0.6.0 and master that could shed some
light on these issues - I'm not familiar enough with the code be able to
tell that from looking at the git log.

Many thanks,
Florian

[1] https://github.com/floe/ltrace/tree/android-master
-- 
SENT FROM MY PDP-11