On Thu, Oct 27, 2011 at 2:55 PM, Steve Fink <[email protected]> wrote: > 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.
DWARF defines CFA to be the value of the stack pointer before the call instruction in the previous frame. gdb's implementation is consistent with this definition. libunwind treats CFA as being synonymous with %rsp, which is probably what you're observing. Using tests/Ltest-bt: Breakpoint 3, 0x0000000000400fec in do_backtrace () at Gtest-bt.c:69 69 unw_getcontext (&uc); (gdb) x /i $rip => 0x400fec <do_backtrace+28>: callq 0x400bd0 <_Ux86_64_getcontext@plt> (gdb) p /x $rsp $2 = 0x7fffffffdf10 (gdb) up #1 0x00000000004016d0 in foo (val=<optimized out>) at Gtest-bt.c:132 132 do_backtrace (); (gdb) p /x $rsp $3 = 0x7fffffffe040 (gdb) info frame Stack level 0, frame at 0x7fffffffe040: UNW_DEBUG_LEVEL=3 ./Ltest-bt 2>&1| grep step.*cfa >_ULx86_64_step: (cursor=0x602420, ip=0x0000000000400ff1, cfa=0x00007fffffffdf10) >_ULx86_64_step: (cursor=0x602420, ip=0x00000000004016d0, cfa=0x00007fffffffe040) >_ULx86_64_step: (cursor=0x602420, ip=0x0000000000400d0b, cfa=0x00007fffffffe090) >_ULx86_64_step: (cursor=0x602420, ip=0x00007ffff762730d, cfa=0x00007fffffffe160) >_ULx86_64_step: (cursor=0x602420, ip=0x0000000000400f0d, cfa=0x00007fffffffe220) I can't think of anything obvious that'd break if we returned a different answer for UNW_X86_64_CFA. Let me think about this a bit more before attempting to implement something. -Arun _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
