mips-tdep.c: Unification of FPR size detection

[Daniel Jacobowitz]

On Thu, Dec 20, 2007 at 04:57:11PM +0000, Maciej W. Rozycki wrote:
>  This patch in its current form assumes if no frame is available, then the 
> width of the registers is irrelevant and because some value has to be 
> provided it uses the native one.

The value you provide then (probably during regcache creation) will
stick around longer than you expect.

> > Right.  But it doesn't change the size of the registers as presented
> > by a remote stub to GDB.  So, for our purposes I think the best model
> > is that the size of the raw FP registers does not change.  How can we
> > change the size of the raw registers while the stub is sending the
> > same bit patterns to GDB?
> 
>  This sounds like a bug in the stub then -- probably an outcome from the 
> semantics of the "ldc1/sdc1" instructions which it may use rather than 
> exposing the actual topology of the register file.  It may have worked 
> reasonably well for legacy MIPS processors, because odd-numbered FP 
> registers were only usable as a high-part of double values, so the FPU 
> could have been effectively treated as one having 16 64-bit FPRs split in 
> an original way.

I'm not talking about the implementation of a stub; I'm talking about
the remote serial protocol and GDB<->stub communications.  One thing
we simply can not do is change the size of the registers in the middle
of a debugging session.  If we do, GDB will have no way to parse the
resulting 'g' packet and locate the status register to check FR.

Some background to be sure we're using the same terminology:

The MIPS port is currently organized with two sets of registers.  One
is the raw registers, those provided by hardware.  The other is the
ABI registers, those defined by the current ABI.  The raw registers
are always used to communicate with the target.  The ABI registers are
always used to communicate with the user.  $f0 is always an ABI
register and its size is always determined by the ABI.

Ideally, the target would define the raw registers and the gdbarch
would define the ABI registers.  In practice it's messier than that,
but that's how it's supposed to work.

You are trying to distinguish the raw registers, used for
communication, from the hardware registers, which effectively change
under software control.  The port is not prepared for that.  The
only mechanism we have to report different sizes for registers
is the creation of a new gdbarch; it seems like the two settings
of the FR bit should correspond to two different gdbarches.  But
selecting a gdbarch based on register values will be tricky.
Possible, though.

How do you detect, or plan to, when the register has changed?  Poll it
every time we stop the target?  Once we know how to detect changes,
that should let us determine when to select an appropriate
architecture.  I'd rather do it in some way that doesn't penalize
debugging performance too badly for existing targets.

Then there's the question of how to present this to the user.  Maybe
we only need to do it for some setting of "set mips abi".  Anything
else is going to involve changing the raw / ABI distinction that the
port is currently designed around.

-- 
Daniel Jacobowitz
CodeSourcery