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

[Lassi Tuura]

Hi,

> 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 ;-(

I agree for more general libunwind use this may not cut the mustard.

For us it happens not to be an issue. Our profiler has limited ability to
rewrite code on the fly, so as long as we can get a symbol address we can
inject a trap into the function code and have all the calls vectored into
our code. So we can get notified of all _dl_debug_state() calls, I think.

The main question to me is if it's any use. I need to understand what state
the system is in when that call happens, what can be done when getting the
call, and how much work it would be to use what ever info we can get. We'd
definitely need to get the trap before dynamic linker goes ahead and calls
global constructors for example, but safe enough to get the load map.

These look relevant - seems you have prior experience here.

 https://bugzilla.redhat.com/show_bug.cgi?id=179072
 http://sourceware.org/bugzilla/show_bug.cgi?id=2328

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

Hm, I have experimental code to make full process memory layout dump, and it
does understand prelinked shared libraries. I need to re-check what I did.

Regards,
Lassi