On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <[email protected]> wrote:
> Another issue continuing to bite us from time to time is the deadlock in
> dl_iterate_phdr() if you attempt to get a stack trace right in the middle
> of dynamic linker holding - or even taking - that lock. Previously it was
> suggested app might trap into _dl_debug_state() to grab the list then tell
> libunwind to use the list not dl_iterate_phdr(). I am willing to see if
> this can fly, but thoughts would be welcome.
There are two problems with this approach (that I know of):
1. On many distributions, _dl_debug_state compiles to a single 'ret'. This
is fine for an external debugger to place a breakpoint on, but is pretty
useless for in-process debugging, as there is just not enough space to
do anything ;-(
Glibc developers were not receptive to our troubles:
http://www.groupsrv.com/linux/about50322.html
See John Reiser comment on Fri Jul 29, 2005 7:26 pm, mentioning r_brk.
I am pretty sure John opened a glibc bug for this (which I can't find),
which got closed as INVALID.
There are ways to work around this, but they are exceedingly unpleasant.
2. For prelinked libraries, the _r_debug.r_map list does not give you
access to the info you need: l_map->l_addr becomes 0 for all images
that are loaded at their desired address!
What you need then is access to l_map->l_phdr, but glibc considers that
member private, and the offset to it changes with different glibc
versions. You lose.
HTH,
--
Paul Pluzhnikov
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
