Getting access to bionic/linker/linker.c
Michael Ambrus
bionic/linker/linker.c
I'm aware of that the public functions need to be wrapped in bionic/
libdl/libdl.c but when I try using dl_unwind_find_exidx from within
code in libc the system will not start.
I'm trying to follow the same method of wrapping/stubbing to get my
own interface working to aid in debugging and I need to understand the
mechanism.
In libdl.c it says:
/* These are stubs for functions that are actually defined
* in the dynamic linker (dlfcn.c), and hijacked at runtime.
*/
Where does this hijacking take place exactly?
Michael Ambrus
MiB, Lund Sweden
Sony Ericsson
The postings on this site are my own and don’t necessarily represent
Sony Ericsson’s positions, strategies or opinions.
Iliyan Malchev
I'm having problems getting run-time access to data/functions in
bionic/linker/linker.c
I'm aware of that the public functions need to be wrapped in bionic/
libdl/libdl.c but when I try using dl_unwind_find_exidx from within
code in libc the system will not start.
How exactly are you trying to use this function? If you want to unwind the stack, then you can look in either system/core/debuggers/, or in bionic/libc/bionic/malloc_debug_leak.c. The latter implements get_bracktrace(), wich calls into _Unwind_Backtrace() (in libgcc.a), which in turn calls __gnu_Unwind_Find_exidx(), which then calls dl_unwind_find_exidx().
I'm trying to follow the same method of wrapping/stubbing to get my
own interface working to aid in debugging and I need to understand the
mechanism.
In libdl.c it says:
/* These are stubs for functions that are actually defined
* in the dynamic linker (dlfcn.c), and hijacked at runtime.
*/
Where does this hijacking take place exactly?
bionic/linker/dlfcn.c is where the functions are actually implemented. The symbol table libdl_symtab is part of libdl_info, which is the soinfo node representing the dynamic loader itself. libdl_info is placed first in the symbol-lookup order, so that if any program links against dlsym(), for example, the reference will be resolved against the implementation of dlsym() in dlfcn.c. libdl contains stubs in order to make the static linker happy.
Michael Ambrus
MiB, Lund Sweden
Sony Ericsson
The postings on this site are my own and don’t necessarily represent
Sony Ericsson’s positions, strategies or opinions.
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Michael Ambrus
thanks for your answer and sorry for taking so long to reply.
Based on your answer I can see that you've interpreted exactly what I
want to do. The file you refer to (malloc_debug_leak.c) is not in my
source-tree however however - I'm on Donut still but I'll have a look at
it from home. What you describe is basically what I want to do and have
done using the functions/macros defined in unwind.h.
The exact point of where I tried to use __gnu_Unwind_Find_exidx() in
bionic was in the fork function, right before the actual syscall. I also
tried using the function from a native and very simple test-program, in
which case the call works fine but GDB seems to get all confused.
I need these abilities to aid debugging in situations where I can't use
either HW debugger nor GDB. I.e. in situations where I have no choice
but to do printf-debugging (to the log i.e.). Debuggerd's implementation
seems to be a bit over the top for my needs (I furthermore don't think I
can afford the run-time to open/read and parse the /proc/../maps).
A bit unrelated to the general topic here, but still very much needed
for me, is also the ability to make calls into bionic/linker/linker.c
(with friends).
Basically, what is needed is to mimic the implementation of
__gnu_Unwind_Find_exidx and I should be fine? I do need these calls from
within bionic and it would be very good know that it should work before
I start.
Kind regards
Michael Ambrus
MiB, Lund Sweden
Sony Ericsson
The postings on this site are my own and don’t necessarily represent
Sony Ericsson’s positions, strategies or opinions.
> To unsubscribe from this group, send email to android-platform
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=en.
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-platform" group.
> To post to this group, send email to
> android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platform
> +unsub...@googlegroups.com.
Michael Ambrus
everything turns out to work fine :) The problem I had originally was
probably that somehow static and dynamic versions of
__gnu_Unwind_Find_exidx got mixed up (don't ask me how, I can't
recreate it anymore).
I couldn't follow your explanation in the the code for libgcc to
eventually end up in __gnu_Unwind_Find_exidx however. It seems
_Unwind_Backtrace instead requires the C-library it's built for to
provide __libunwind_Unwind_Backtrace. I guess I'm either looking in an
older code or that the symbol is replaced somehow when the tools are
built.
In the pre-built libgcc.a the reference is obviously there however:
00000000 w *UND* 00000000 __gnu_Unwind_Find_exidx
Thanx much for your help!
Kind regards
Michael Ambrus
MiB, Lund Sweden
Sony Ericsson
The postings on this site are my own and don’t necessarily represent
Sony Ericsson’s positions, strategies or opinions.
On Mar 17, 6:04 pm, Michael Ambrus <michael.amb...@sonyericsson.com>
wrote: