Re: [PATCH] Look for FIR in the last FreeBSD/mips floating-point register.

[John Baldwin <jhb@freebsd.org>]

On Thursday, June 08, 2017 08:15:39 AM Maciej W. Rozycki wrote:
> On Wed, 31 May 2017, John Baldwin wrote:
> 
> > FreeBSD/mips kernels were recently changed to include the floating
> > point implementation revision register in the floating point register
> > set exported in process cores and via ptrace() (r318067).  This change
> > will first ship in FreeBSD 12.0 when it is eventually released.  The
> > space used to hold FIR was previously reserved in 'struct fpreg' as a
> > zero-filled dummy for padding, so 'struct fpreg' has not changed in
> > size.  On the one hand this means that there is not an easy way to detect
> > if if the FIR register is the zero-filled dummy or the true FIR value.
> 
>  Well, CP1.FIR is generally expected to hold non zero; in particular in 
> legacy MIPS processors (before CP0.Config1.FP was defined) checking for a 
> non-zero value in CP1.FIR (bits 15:8 specifically) was the recommended way 
> to detect the presence of FPU hardware[1].  And from MIPSr1 on there have 
> to be floating-point formats supported reported in CP1.FIR, with D and S 
> being mandatory, so you'll see non-zero bits at least in their positions 
> (the W bit was only added with MIPSr2).

Ah, I had been going off of my (probably stale) copy of See Mips Run which
only talks about comparing FIR with 0.  FreeBSD requires MIPSr3, so it should
always see a non-zero FIR then.

> > However, it also means that there is no need to deal with multiple
> > layouts of 'struct fpreg'.  I've chosen to always treat the last register
> > in 'struct fpreg' as the FIR.  This means that process cores and
> > ptrace() on older kernels will report a FIR value of 0.  However, FreeBSD
> > doesn't currently ship a release image for FreeBSD/mips, and releases
> > prior to 12.0 assume soft-float, so I think this is a reasonable tradeoff
> > for simplicity.
> 
>  You could also exclude a zero CP1.FIR from the view at the GDB side, 
> pretty much how e.g. support for the optional DSP registers has been 
> implemented.  As noted above the setting of zero bears no value anyway.

It ends up being a one-line change to just exclude a zero FIR, so I can do that.

-- 
John Baldwin