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


Michael Snyder wrote:
> 
> Andrew Cagney wrote:
> >
> > Alexandre Oliva wrote:
> > >
> > > read_relative_register_raw_bytes_for_frame() would optimize access to
> > > FP_REGNUM by not re-reading it when the value of FP is already known.
> > > However, because FP is not always available, sometimes the value of SP
> > > is stored in the frame structure as the value of FP.  In this case,
> > > reading the value of FP_REGNUM will get you SP instead of the actual
> > > value of the FP register.  This patch fixes this bug.  Ok to install?
> >
> > I'm not sure about this.
> >
> > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer /
> > frame-base variable.  It doesn't refer to the ISA register that is seen
> > in architectures such as ARM or VAX.  Unfortunatly, some architectures
> > have both and this leads to confusion.
> 
> 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().

	Andrew

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