Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?

[Paul Pluzhnikov]

On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <address@hidden> 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