[Ltrace-devel] ARM support

Florian Echtler floe at butterbrot.org
Mon May 7 13:05:56 UTC 2012


On 05.05.2012 02:01, Petr Machata wrote:
> 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...]

> 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.
Actually, as I've found, that's not the case after all - I've run into a
different case where two consecutive libraries were mapped into
significantly different address spaces, but still all symbols were
applied with an offset of 0x100000. Indeed, in linker.h from bionic:

#define LIBINC  0x00100000

which is apparently exactly what caused most issues. No idea what this
is or why it's there...

> 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).
I've also merged my patch into libs (android-libs in my repo). However,
it doesn't seem to process already-loaded libraries (i.e., linkmap_init
is never called)?

> 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.
Thanks, the difference between libs and android-libs is now pretty small
- helps to focus on the important parts :-)

> 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?
The blacklists are just a hack for my specific use case. The altpath,
however, was necessary at least in the other branches to actually find
the library so files - not sure how the libs branch will handle this, as
linkmap_init seems not to be called right now.

Florian
-- 
SENT FROM MY PDP-11



More information about the Ltrace-devel mailing list