This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ARM frame fp is not always FP_REGNUM


> > 
> > Huh???  FP_REGNUM refers to a register.
> > The "fp" that is displayed by "info registers" sometimes
> > refers to gdb's internal pseudo-frame or virtual frame location,
> > but the constant FP_REGNUM is a real hardware register.
> 
> I read it as the hardware or pseudo register that directly corresponds
> to GDB's ``$fp'' pseudo register.  parse.c:build_parse() maps $fp ->
> FP_REGNUM.  (mental note, fix buffer overrun in build_parse()).  Some
> targets have a real $fp (ARM, VAX) so the obvious thing to do was to map
> FP_REGNUM onto the real register.  Other targets don't have a real $fp
> so it is mapped onto a pseudo register (MIPS).
> 
> As Alexandre pointed out, things relied on pseudo-$fp <-> FP_REGNUM <->
> frame->frame <-> hardware-$fp but in modern times, with frameless
> functions, this makes little sense.
> 
> My reading of the doco is that, when the target has a true hardware $fp,
> then the pseudo $fp register shouldn't be provided.  Per other e-mail, I
> think this can be implemented by invalidating FP_REGNUM (set it to -1)
> and instead provide read_fp() and write_fp().

On ARM, FP is a well-known alias for R11.  Giving the value of any 
register other than r11 if the user types $fp would be *very* misleading.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]