Re: [Libunwind-devel] local vars

[Steve Fink]

On Sat, Oct 29, 2011 at 2:06 PM, Lassi Tuura <address@hidden> wrote:
>
> What I meant before about straddling is that, at least to my understanding,
> the way unw_step / dwarf_step / apply_reg_state works is that we return info
> for a frame *as seen from* the callee frame, at the point of call. We have
> not actually stepped into the caller frame yet at that point.
>
> So unw_getcontext() returns info on register state, including %rip, at the
> point of call from do_backtrace() into unw_getcontext -- but internally in
> the cursor object, the *frame* is that of getcontext. After one unw_step(),
> the libunwind cursor is actually pointing to the frame of do_backtrace(),
> while returning info about the point of call from bar().
>
> It turns out this works for almost everything because you actually do see
> %rip and register state as if it was for the frame caller frame. But it does
> not work for returning the CFA. In fact we have no idea what the CFA is for
> the caller frame, since we haven't yet looked up its DWARF info or executed
> the CFI program.

I was thinking that might be the case. Perhaps then you just rename
the accessor to UNW_CALLEE_CFA and leave it exactly as it is now. (Why
isn't there a platform-independent name for the CFA, btw? Heck, right
now you could just #define UNW_REG_SP UNW_CFA!)

But that suggests to me that the current implementation of
UNW_X86_64_RSP is not completely correct. It is assumed to be equal to
the callee's CFA (or really, the current frame's caller's sp is equal
to the current frame's CFA), which is not guaranteed. (The CFA I am
generating for my JIT code, in fact, does not follow this pattern. But
you never see that CFI since it's not in the object file; I can do
something different with libunwind-dynamic if needed.) When using
DWARF, shouldn't sp be retrieved according to the CFI same as any
other register?

Oh. I researched this a bit. The CFI normally does not give a rule for
sp, because earlier versions of DWARF could not express a valid rule.
(You want the value of CFA plus a constant, most likely zero, but
originally the only option was to load a value from stack memory at
CFA+k. Now there are val_offset(k) rules.) And it's almost always just
the CFA anyway, so it's considered an "architectural" rule (a default
rule based on the arch in use), so you don't even need to put it in
the CIE.

So never mind. Leaving the saved SP to be identical to the CFA seems
plenty Good Enough. Though it might be nice to use a DWARF rule if one
happens to have been defined for the sp.