ARM frame fp is not always FP_REGNUM
Andrew Cagney
ac131313@cygnus.com
Tue Jul 4 01:09:00 GMT 2000
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
More information about the Gdb-patches
mailing list