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

[Joe Damato]

On Mon, Mar 21, 2011 at 1:57 PM, Paul Pluzhnikov <address@hidden> wrote:
> 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.

Seems like you may just be able to write a software breakpoint over
the ret instruction and install a signal handler to catch it. Sorry if
I'm joining this conversation late, I'm trying to find the original
context to see if I can help. I implemented libdl support in ltrace
not long ago so I played around with r_debug and r_brk quite a bit.

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

AFAIK, RT_CONSISTENT is set and _dl_debug_state() is fired _before_
constructors are executed.

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

Again, pardon me being late to this conversation. I need to go back
and see what you guys are trying to do, exactly, but perhaps you could
use dl_iterate_phdr?

joe