Re: mips-tdep.c: Unification of FPR size detection

[Daniel Jacobowitz <drow@false.org>]

On Wed, Dec 19, 2007 at 05:07:42PM +0000, Maciej W. Rozycki wrote:
> > This part does not make sense to me and it suggests that the patch is
> > wrong.  In general, if you have a function that wants something to do
> > with a frame and there isn't a frame available you have a design
> > problem.
> 
>  Well, I do not insist on getting through to the cp0.Status register 
> through the frame.  It is just that with the recent removal of the 
> globally accessible "current_regcache" variable, you cannot get at the 
> register file otherwise than through the frame.  I am looking forward to 
> suggestions as to how to access the register bypassing the frame 
> infrastructure.

No, that's the exact opposite of what I meant.  If you don't have a
frame available, then you have to assume the target essentially has no
registers (yet, or any longer, or...).  So we can not make any
decisions based on their values.  If you're caching the value,
it seems suspiciously to me like guessing an arbitrary wrong value,
maybe even from a previous session.

> > The target's registers are a certain size.  That's independent of the
> > FR bit, which should affect only what we put into the registers and
> > how we interpret the results.  We can not change the type of registers
> > during execution; the regcache caches the types and sizes.  Anything
> > dependent on the FR bit can change during execution, so it can not be
> > a property of the gdbarch (which the return value of
> > mips_register_type is).  It should be possible to make the types of
> > the pseudo-register view change based on FR, though it might upset
> > other bits of GDB; I'm not sure without trying it.  But the raw
> > register has to stay fixed.
> 
>  That is actually incorrect.  We do not have to know how it is implemented 
> internally in a given CPU and I am told it may indeed vary, but in 
> principle cp0.Status.FR does actually change the width of raw floating 
> point registers.

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?

Something needs to change, sure, but I don't think this is it.

-- 
Daniel Jacobowitz
CodeSourcery