[Ltrace-devel] ARM support
Florian Echtler
floe at butterbrot.org
Thu May 3 16:34:51 UTC 2012
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
More information about the Ltrace-devel
mailing list