Re: dwarf2 and frame bases

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Nov 11, 2004 at 08:48:52AM -0800, Randolph Chung wrote:
> so, if you are at the first insn of the prologue, and you unwind r3, you
> would get the *previous frame*'s frame base.  if you used this value to
> calculate the address of your locals, you will get the value they have
> in the previous frame.

Correct.  A watchpoint on "b" is associate with a particular frame,
because it's a local.  You want the previous frame's copy.  You get the
previous frame's copy.  Everyone wins.

> sounds like it should still work (i.e it should still be a valid
> address), except the hppa targer has an explicit check for when we
> expect r3 to be modified but we may be in the process of changing it
> (since it's a 3 insn sequence). In that case, we zero the register to
> tell the unwinder not to use the value in the r3 to calculate the frame
> base (it uses the stack pointer and other unwind information in that
> case)
> 
> See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00108.html for
> more details.

This sounds totally messed up.

Suppose we're in frame A, called from frame B.  We're at the first
instruction.  If we ask the sentinel frame to unwind the value of r3,
we'll get its real register value - regardless of where we are in the
sequence.  If we ask frame A to unwind r3, we want to get frame B's r3.
Where frame A is in its prologue has no effect on what frame B's r3 was
at the time of calling A.

There's no more details in that message, just a patch :-)  I can't
trace exactly what it's doing.

> i know it is kind of hacky, but the frame unwinding code is explicitly
> asking "what is the frame base of this frame", and the target code is
> especially tuned for that..... 
> 
> i see two possible solutions:
> 1) perhaps the hppa target should use some other mechanism (instead of 
>    mucking with r3) to tell the next frame that the frame pointer is 
>    not available.....

The next frame's frame pointer _is_ available.  This is what I don't
understand.  You were asked, "unwind r3 for frame B" and instead you're
zeroing it based on where frame A is?

> 2) in the dwarf code, when trying to get the frame base, should we
>    explicitly ask for the frame base instead of using the dwarf 
>    expression? perhaps this could be something that can be overridden
>    by the target, so that the default still uses the dwarf information.

No.  The "frame base" as a GDB concept is completely separate from
DW_AT_frame_base used for local variables; let's not confuse them
further.

-- 
Daniel Jacobowitz