libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] local vars


From: Arun Sharma
Subject: Re: [Libunwind-devel] local vars
Date: Mon, 31 Oct 2011 01:25:02 -0700

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.
>

bar+offset: call <foo>
label1:       next_instruction

if you put a gdb breakpoint on label1: and examine the registers, they
should match the dwarf_cursor (including rip, rbp and rsp) when
dwarf_cursor.ip == label1. No state is in flux. Everything is precise
at the instruction boundary.

Now the commonly understood concept of CFA at this point in the
execution is the value of %rsp when bar returns to its caller, whereas
dwarf_cursor.cfa is essentially %rsp at label1. This is the
discrepancy I'm trying to address.

[...]

> So in a sense, the information for UNW_X86_64_CFA trails the other info by
> one frame, because the internal state really still points to the callee.

Internal state should point to the caller. Only CFA is lagging by one
frame. This is addressed by apply_reg_state(). The first thing it does
is recompute CFA, so the off-by-one issue is corrected and everything
works magically.

> Were you thinking of some way of returning CFA info easily, by shifting the
> internal state somehow by one stack frame?

I was thinking of shifting this computation:

apply_reg_state:

 /* Evaluate the CFA first, because it may be referred to by other
     expressions.  */

to the end of the function, instead of being at the beginning. But
that won't work. The problem is: the CFA evaluation expression is
computed by run_cfi_program() on caller's IP address range, not
callee's. So the information needed to compute the CFA is not
available until the next call to apply_reg_state.

For now, I'd suggest that callers of libunwind compute the value of
CFA by reading the value of stack pointer in the next outer frame.

 -Arun



reply via email to

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