From: "Maciej W. Rozycki" <macro@imgtec.com>
To: John Baldwin <jhb@FreeBSD.org>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Look for FIR in the last FreeBSD/mips floating-point register.
Date: Thu, 08 Jun 2017 07:15:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1706080744320.21750@tp.orcam.me.uk> (raw)
In-Reply-To: <20170531165803.50633-1-jhb@FreeBSD.org>
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).
You'll only ever see zero in CP1.FIR with some broken simulators, which
therefore cannot be relied on being a correct architecture implementation
anyway.
> 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.
References:
[1] "IDT MIPS Microprocessor Family Software Reference Manual", Version
2.0, Integrated Device Technology, Inc., October 1996, Chapter 8
"Floating Point Co-Processor", p. 8-9
Maciej
next prev parent reply other threads:[~2017-06-08 7:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 16:58 John Baldwin
2017-06-05 20:27 ` Simon Marchi
2017-06-06 17:49 ` John Baldwin
2017-06-08 7:15 ` Maciej W. Rozycki [this message]
2017-06-12 18:47 ` John Baldwin
2017-06-12 20:23 ` Maciej W. Rozycki
2017-06-13 16:43 ` John Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1706080744320.21750@tp.orcam.me.uk \
--to=macro@imgtec.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox