This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Look for FIR in the last FreeBSD/mips floating-point register.
- From: John Baldwin <jhb at freebsd dot org>
- To: gdb-patches at sourceware dot org
- Cc: "Maciej W. Rozycki" <macro at imgtec dot com>
- Date: Mon, 12 Jun 2017 11:47:39 -0700
- Subject: Re: [PATCH] Look for FIR in the last FreeBSD/mips floating-point register.
- Authentication-results: sourceware.org; auth=none
- References: <20170531165803.50633-1-jhb@FreeBSD.org> <alpine.DEB.2.00.1706080744320.21750@tp.orcam.me.uk>
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