[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