Re: varobj's find_frame_addr_in_frame_chain hack (and other ARM unwindnotes)

[Andrew Cagney <ac131313 at redhat dot com>]

> On Mon, Jun 30, 2003 at 03:04:42PM -0400, Andrew Cagney wrote:
>
> > >varobj.c:find_frame_addr_in_frame_chain, and mi-var-display.exp.  We print
> > >out $fp, and use then search for that value in the frame chain.  Well,
> > >the DWARF-2 CFA value on ARM is biased from the frame pointer register,
> > >generally by four bytes.  I chose to use the same thing in the prologue
> > >unwinder for consistency - it makes unwinding ARM_SP_REGNUM simpler, which
> > >we need to get right in order for dummy frames to work.
>
> > Two wrongs, and they don't make a right :-(
> >
> > - the arm shouldn't be setting / forcing FP_REGNUM
> > Instead, "fp" should always be the frame base.
>
>
> $fp refers to a particular register on ARM.  Are you saying that print
> $fp should print the frame base, and not the contents of the frame
> pointer register?  Personally I'd find that pretty surprising.  Sure,
> call it $frame if you want, but $fp is expected to be $r11 (in ARM
> mode).

If the ISA has a register called $fp then $fp prints that register's 
value, else, $fp prints the `frame base' (which should be `frame locals 
address').  There's also a change-request open for someone to check that 
the Arm really does follow this behavior (compare `info registers fp' 
with `print $fp').

Anyway, the upshot is that, for scripting purposes, $fp is useless.

There is my patch to add $frame or $gdb.frame kicking around.

> > - the test shouldn't be using $fp to re-find a frame
> > It should be using a frame ID, but that involves interface changes to 
> > the MI -> MI 4.

> So.... what, should I just ignore the failure or should I make the
> get_frame_base_address change?

Unless you're up to revamping the MI interface so that it takes frame 
IDs ... :-).

Andrew