mips-tdep.c: Unification of FPR size detection

Maciej W. Rozycki macro@mips.com
Thu Dec 20 16:58:00 GMT 2007

On Wed, 19 Dec 2007, Daniel Jacobowitz wrote:

> 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.

 Well, for whatever reason a frame is commonly not available during a 
debugging session -- I think it gets invalidated at some point and the 
problem is in the process of being reestablished the size of the FP 
registers is being determined.  I can see if I can get a backtrace leading 
to this scenario.

 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.

> 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.

 It is misleading for current (MIPS rev.2) processors though as in the 
32-bit FPR mode all the registers are full-featured single FPRs and also 
the paired-single and fixed long type are not supported with pairs of 
registers even though the double type is.

 I am not sure that pretending the architecture of the FPU is different to 
what it actually is is going to gain us anything.

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

 Any proposals then?  Either way cp0.Status.FR has to be checked -- either 
for the width of FPRs (64-bit vs 32-bit) as in the patch proposed or for 
the number of them (32 vs 16) if the width is pretended to be always 


More information about the Gdb-patches mailing list