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

[Paul Pluzhnikov]

On Mon, Mar 21, 2011 at 1:41 PM, Lassi Tuura <address@hidden> wrote:

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

It sounds like you are ptracing the executable, in which case you *are*
an external debugger, and so (naturally) have no difficulty.

> 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

These are different. I think John had a bug (or maybe it was a rejected
patch). Instead of:

  _dl_debug_state();

he did:

  (*_r_debug.r_brk)();

which nicely allows in-process debugger to install whatever hook it wants
without any need to patch code.

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

It's easy to do this by looking at /proc/self/maps, but it's not fast,
and /proc may not be mounted at all, etc. etc.

HTH,
-- 
Paul Pluzhnikov