This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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

 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.

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]