Re: [Libunwind-devel] local vars

[Arun Sharma]

On Thu, Oct 27, 2011 at 2:55 PM, Steve Fink <address@hidden> 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 <address@hidden>
(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