Re: [Libunwind-devel] local vars

[Steve Fink]

On Fri, Oct 28, 2011 at 7:20 PM, Arun Sharma <address@hidden> 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, &reg);
  saved_info[i].ip = reg;
  unw_get_reg(&cursor, UNW_CFA, &reg);
  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.