On Fri, Oct 28, 2011 at 7:20 PM, Arun Sharma <[email protected]> wrote: > Re-reading your first message, all your looking for is a solid > definition of CFA in libunwind and as long as you're using the same > concept of CFA in C++ and JIT'ed frames, everything is good?
I don't even care about the CFA matching between C++ and JIT frames, since I already have to handle them independently. All I really want is for the CFA to apply to the "current" frame. Specifically, if I am using a libunwind cursor and read out the IP register and find it to be *within* some function f(), when I fetch the CFA for that same cursor position, I want it to be usable to access the parameters and locals (and saved registers, though I'm not using those). Right now, it's one frame off, so I have to use the CFA for one of the callees of f(). I am handling it by scanning over the full stack and saving my own copy of the return addresses and cfas, only I write the cfa into a different index than the return address, something like: unw_get_reg(&cursor, UNW_REG_IP, ®); saved_info[i].ip = reg; unw_get_reg(&cursor, UNW_CFA, ®); saved_info[i-1].cfa = reg; So it's the off-by-one that mainly bothers me. However, I would *prefer* the definition of the CFA match the DWARF info. That means when using DWARF info, there would be no explicit connection in the code between the CFA and the stack pointer. The CFA would be whatever the CIE+FDE evaluate to at the exact instruction of the saved IP. (It's the same value throughout the frame, but how it gets computed varies according to what the CFI says for that ip.) That would make it easier to cross-check with GDB and other DWARF readers. > > How about going with this definition: libunwind CFA == value of stack > pointer at the IP address in question. In the absence of DWARF info, my preferred definition would be the value of the stack pointer at the beginning of the call instruction immediately preceding the IP address (a return address), since I think that's sort of the default. And if that's hard, the current definition (same as the saved SP) would be fine if it were shifted by one frame. It's actually a little messier even than that, because the whole thing about backing up one call instruction only makes sense for regular stack frames. A signal handler should not back up any instructions. (We ran into a related but different problem recently -- see https://bugzilla.mozilla.org/show_bug.cgi?id=695985 ). But really, the current definition would be fine, if it were shifted by a frame. As long as I can get to a local variable with the same offset whenever I find a return address within a given function, I'm good. Having that offset match what's computable by DWARF info is just a bonus. _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
