[Ltrace-devel] ARM support

[Petr Machata]

Florian Echtler <floe at butterbrot.org> writes:

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

Ah, but of course!  That would explain why it's trying to apply offsets
to the wrong library.  The trick is that library is indexed differently
from lte.  This is my fix, and it's wrong, I didn't notice that they are
indexed differently.  But when written the original way, it leads to
essentially the following code:

crawl_linkmap(callback, struct ltelf *lte):
        callback(lte);

hook_libdl_cb(struct ltelf *lte):
        library[library_num++] = strdup(lib_name);
        lte[library_num].base_addr = addr; // <-- buffer overrun

int linkmap_init(struct ltelf *lte):
        crawl_linkmap(hook_libdl_cb, lte);

extern struct ltelf main_lte;

Event *next_event(void):
        linkmap_init(&main_lte);

So it's kind of choose your bug.

The libs branch replaces most of that logic, so it will take care of
this naturally when it is merged.  I fixed the compilation issues
(though not the SIGILL issues that I'm seeing, but I see those on master
as well).

FYI, I went over your patchset and ported the ptrace() fixes to libs
branch, those seem obviously correct.  I think the error() fixes are not
relevant anymore, I moved uses of error in generic code to fprintf.  The
stuff related to _ElfW was changed as well and is not present anymore.

I don't understand most of the code related to blacklists and altpath,
so I'm leaving it alone.  Is it necessary, or is it just a hack to get
things working?

Thanks,
PM