On Mon, Mar 21, 2011 at 1:57 PM, Paul Pluzhnikov <[email protected]> wrote: > On Mon, Mar 21, 2011 at 1:41 PM, Lassi Tuura <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
