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