[Ltrace-devel] ARM support

[Petr Machata]

Sorry this took so long, I was on vacation last week.

Florian Echtler <floe at butterbrot.org> writes:
> 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...

Interesting, but I'm not sure this is related.  I'm looking into the
code that I found on https://gitorious.org/0xdroid/bionic and LIBINC
seems to be related to a buddy allocator system that they use to place
libraries to memory in the dynamic linker.  Newer bionic code
(https://github.com/android/platform_bionic) doesn't contain this code
at all and apparently just relies on kernel ASLR support to find the
right spot.

>> 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)?

That would mean that _start is never hit.  With debugging (-D77), ltrace
start-up should look something like this:

DEBUG: execute_program.c:77: Executing `/bin/echo'...
DEBUG: sysdeps/linux-gnu/trace.c:103: trace_me: pid=6674
DEBUG: execute_program.c:96: PID=6674
DEBUG: dict.c:60: dict_init()
DEBUG: breakpoints.c:392: breakpoints_init(pid=6674)
DEBUG: ltrace-elf.c:307: do_init_elf(filename=/proc/6674/exe)
DEBUG: ltrace-elf.c:308: Reading ELF from /proc/6674/exe...
DEBUG: ltrace-elf.c:464: /proc/6674/exe 35 PLT relocations
DEBUG: ltrace-elf.c:476: do_close_elf()
DEBUG: proc.c:698: proc_add_breakpoint(pid=6674, (null)@0x4016bc)

That last line adds breakpoint for binary entry point (_start).  At some
point in future, you should see something like the following:

DEBUG: sysdeps/linux-gnu/events.c:310: event: BREAKPOINT: pid=6674, addr=0x4016bc
[...]
DEBUG: dict.c:132: dict_remove(0x4016bc)
DEBUG: sysdeps/linux-gnu/proc.c:538: linkmap_init()
DEBUG: sysdeps/linux-gnu/proc.c:296: find_dynamic_entry()
DEBUG: sysdeps/linux-gnu/proc.c:317: found address: 0x7f6f1a917260 in dtag 21
DEBUG: sysdeps/linux-gnu/proc.c:494: load_debug_struct
DEBUG: breakpoints.c:209: insert_breakpoint(pid=6674, addr=0x7f6f1a705a20, symbol=NULL)
[...]
DEBUG: sysdeps/linux-gnu/proc.c:420: crawl_linkmap()

That's when _start is hit, which prompts linkmap_init, and leads to
installation of rdebug breakpoint.  That is necessary for dlopen
tracing.  But even if this fails, basic tracing should still work.

However if ltrace fails to add entry breakpoint at all, it gives up
tracing.  That is suboptimal, I fixed it on the branch so that even if
entry breakpoint can't be added, basic tracing still works:

$ ./ltrace -e* echo -n =====
Couldn't initialize entry breakpoint for PID 10973.
Some tracing events may be missed.
echo->__libc_start_main(0x401090, 3, 0x7fff739ab3c8, 0x403af0, 0x403b80 <unfinished ...>
echo->getenv(0x404325, 0x7fff739ab3c8, 0x7fff739ab3e8, 0x403af0, 0x403b80)
[... etc ...]

Getting ltrace to work like this would now be the first step.  We can
focus on figuring out why the advanced stuff (walking linkmap,
instrumenting rdebug randezvous) doesn't work then.

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

Yeah, we will see what's in the link map.  Hopefully the dynamic linker
will give us full path.

Thanks,
PM