On Mon, Jul 06, 2009 at 04:06:55PM +0200, Lassi Tuura wrote: > Ah thanks, yes. As our profiler rewrites (some) machine code on the > fly, it looks like I could vector ourselves into _dl_debug_state() > dynamically at run time, capture a copy of the information and find a > way to teach libunwind to use the private data instead.
Looks like you're lucky - _dl_debug_state is only one byte, but glibc generally has padding before the next function. Should work. > I did run into functions that had non trivial CFA location; it wasn't > a straight register value but some sort of an expression. I'll do > more research to see what exactly happens in functions using alloca() > / vla, and what the DWARF info looks like. This could also be a dynamic stack realignment (for support of vectorization). I didn't think x86-64 needed that, though. -- Daniel Jacobowitz CodeSourcery _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
