I have a function js::Interpret which calls InterpreterFrameStart which does some libunwinding. In gdb, when I use 'info frame' while inside InterpreterFrameStart, it says that my frame is at 0xc930, and the calling frame is 0xde40. (I'm shortening hex values for simplicity.) When I first initialize libunwind and ask it for UNW_X86_64_CFA, it tells me 0xc140. If I unw_step() once, then it gives 0xc930 for the CFA.
In other words, gdb's notion of the CFA seems to be one frame different from libunwind's. That initial CFA of 0xc140 is equal to the current sp, which to me is not a CFA yet -- if I were to call a function, it would be that function's CFA. So libunwind seems to be off by one. Which is survivable if that's what it's defined to mean. Can I assume that? --- The bigger question is how to do this portably. I'm trying to access a local variable in two different types of frames. One is a regular C++-generated frame, where I need the parameters to the function. I've been computing the difference between the address of each parameter and the CFA, remembering that, and then using that offset at a later time when I'm walking the stack and encounter that particular function. The other frame is generated by a JIT, and what I want is a hand-generated "local" struct that also ends up being passed to called functions as the first parameter. So again, I use the CFA of the frame and add a known offset to find the struct, then pull the information out. The JIT stuff is manageable, because I control what's happening and can work around problems easily enough, though I'd like it to work similarly to a compiler-generated frame. The compiler-generated one is trickier, because of the above uncertainty with the CFA's meaning, and because only x86-64 has the CFA register. Oh, wait, looks like the latest libunwind has the CFA for a bunch of architectures. Yay! So maybe this can be portable after all, if I can rely on the off-by-one CFA semantics? Even more irrelevant detail: I'm trying to use libunwind to generate unified stack traces for a Javascript engine (Mozilla's SpiderMonkey). I want to see the stack of C++ frames interleaved with javascript frames, but currently the JS (javascript) frames are allocated on the heap, so I need to know how to interleave them. There are local variables that tell me which JS frames correspond to a given JIT frame or call to the interpreter. I suppose it'd be nice if libunwind had support for examining locals via DWARF and libunwind-dynamic info, but really that's the least of my problems and straightforward to do manually. Thanks, Steve _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
