mips-tdep.c: Unification of FPR size detection
Maciej W. Rozycki
Wed Dec 19 17:15:00 GMT 2007
On Sun, 16 Dec 2007, Daniel Jacobowitz wrote:
> I'll take your word for this part... I find the various FP modes confusing.
Well, no surprise here and the addition of the 64-bit mode to MIPS32r2
has not made the view any clearer...
> 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
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
Actually my long-term idea was to read the register when available and
cache the value of the flag in the target code for cases when it is not
accessible through the regular register cache.
> 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
With the bit set all the FPU registers fp0 through to fp31 are 64-bit
wide. All the double FP operations are performed on single registers.
All the single FP operations are performed on single registers.
With the bit clear all the FPU registers fp0 through to fp31 are 32-bit
wide. All the double FP operations are performed on consecutive odd/even
pairs of registers. All the single FP operations are performed on single
registers. Note that there is a difference here between MIPS Architecture
and legacy MIPS processors. For the formers all the registers may be used
in this mode with single FP operations. For the latters only
even-numbered registers are permitted.
> 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?
It is the raw hardware register size and as explained above we do want to
check mips2_fp_compat(). I have a patch in the queue that makes cooked FP
registers always be 64-bit though.
> 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.
There may be no ABI. GDB may just be connected to a running target,
through EJTAG for example, with no executable selected. In this case the
only source of information of the FPU configuration is hardware. I used
it this way in the past. And in particular, when debugging the Linux
kernel, it may change the setting of cp0.Status.FR under your feet, so
whenever execution stops, the width of the FP register stack has to be
updated following the state of the bit.
More information about the Gdb-patches