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

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Nov 21, 2007 at 05:40:28PM +0000, Maciej W. Rozycki wrote:
>  I think the changes are mostly obvious.  If not, then please enquire.  
> Modifications to mips_o32_return_value(), mips_o32_push_dummy_call() and 
> mips_register_type() change the semantics somewhat, but this is correct as 
> for 64-bit processors in the compatibility mode FPRs are seen as 32-bit.  
> The rest just shuffles code for consistency.

I'll take your word for this part... I find the various FP modes confusing.

>  One note: the mips2_fp_compat() function is meant to detect the size of 
> floating point registers based on the setting of the cp0.Status.FR bit as 
> applicable.  However the function currently always returns 0.  So I 
> decided to include a change that ifdefs out the entire body.  Enabling the 
> body does not trigger any new regressions.  I also added a note on a 
> problem with the frame being NULL -- it may have to be dealt with in a 
> better way once this code is reenabled.  A possible way is by caching the 
> value of cp0.Status.FR elsewhere.

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.

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.

So, which is mips_float_regsize supposed to be?  The hardware
register size, in which case it should not call mips2_fp_compat,
or the software register size?

Maybe we should rip mips2_fp_compat out entirely.  We'd need yet
a third layer of registers since we already have one for the ABI.


-- 
Daniel Jacobowitz
CodeSourcery