[Ltrace-devel] ARM support

[Florian Echtler]

On 04.05.2012 01:11, Petr Machata wrote:
> Florian Echtler <floe at butterbrot.org> writes:
>> /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.
After a lot of failed merge and rebase attempts and learning a bit more
about git, I've managed to run "git bisect" between my branches
android-0.6.0 (more or less working, crash-prone) and android-master,
which pointed me to the following commit:

commit 141f18180ee6255ee0c11c05e850924cad3392dc
Author: Petr Machata <pmachata at redhat.com>
Date:   Thu May 19 16:09:17 2011 +0200

    Fix a buffer overrun bug

diff --git a/sysdeps/linux-gnu/proc.c b/sysdeps/linux-gnu/proc.c
index 2cbc696..0f25780 100644
--- a/sysdeps/linux-gnu/proc.c
+++ b/sysdeps/linux-gnu/proc.c
@@ -251,8 +251,8 @@ hook_libdl_cb(void *data) {
        lte = hook_data->lte;

        if (library_num < MAX_LIBRARIES) {
-               library[library_num++] = strdup(lib_name);
                lte[library_num].base_addr = addr;
+               library[library_num++] = strdup(lib_name);
        }
        else {
                fprintf (stderr, "MAX LIBS REACHED\n");

When I revert this change in my master branch, things get back to
partially working as before (*). Petr, can you shed any light on what's
happening here? I have to admit I don't really have any clue.

> So... yeah, it seems like it's something in Android rubbing ltrace the
> wrong way.
After looking at the git bisect result, I'm not quite sure that Android
itself is to blame, it may also be some subtle bug introduced by my
patch (e.g. in hook_libdl_cb, addr is inserted into the wrong "struct
ltelf" item or somesuch...)

Florian

(*) Which is weird enough in itself, since this is quite obviously a
necessary bugfix.
-- 
SENT FROM MY PDP-11