[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libunwind-devel] local vars

From: Steve Fink
Subject: [Libunwind-devel] local vars
Date: Thu, 27 Oct 2011 14:55:36 -0700

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]