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

[Joe Damato]

On Mon, Mar 21, 2011 at 12:04 PM, Paul Pluzhnikov
<address@hidden> wrote:
> 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!

l_addr is the difference between the on disk address in PT_LOAD and
the in memory address of the library. AFAIK, you will have to parse
some of the headers of the library (on disk) to figure out the base
load address. there's no way around that.

joe