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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
