Re: ARM frame fp is not always FP_REGNUM

[Andrew Cagney <ac131313 at cygnus dot com>]

Alexandre Oliva wrote:
> 
> On Jul  4, 2000, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > Alexandre Oliva wrote:
> 
> >> On ARM, it's register 11, which is a real register.  But SP_REGNUM is
> >> register 13.  Then, when framereg == 13 in EXTRA_FRAME_INFO, `info
> >> regs' will display the value of r13 for r11, and the actual value of
> >> r11 cannot be obtained.
> 
> > How does this compare to when you do an info registers when at the inner
> > most frame?
> 
> That's exactly the case.
> 
> Given this sample assembly program:
> 
>         .global _start
> _start:
>         mov     r11, #1
> 
> After executing the first instruction, GDB will print:
> 
> (gdb) info reg
> [...]
> r11            0x800    2048
> r12            0x0      0
> sp             0x800    2048
> [...]
> (gdb) p $fp
> $1 = 1
> 
> > This suggests that providing the ``$fp'' pseudo register is wrong for
> > this target.
> 
> Or that, on ARM, $fp should obtain the value of frame->framereg,
> instead of FP_REGNUM.

``Same diff?'' :-)  Hmm, actually, no. The documentation is saying that
when the hardware has a real $fp, $fp always refers to that hardware
register.  That would be returned by:

  get_saved_register (myaddr, &optim, (CORE_ADDR *) NULL, frame,
                      regnum, (enum lval_type *) NULL);

Neither ->framereg nor FP_REGNUM need to even come into the picture.  To
do it, I think you would need to:

	o	redefine FP_REGUM to -1 which
		indicates that it is invalid.

	o	use something else in arm-tdep.c
		I would strongly recommend something
		name space proof like
		enum { ARM_FP_REGNUM = ...};

	o	implement read_fp() and write_fp()

enjoy,
	Andrew