From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44816 invoked by alias); 12 Jun 2017 18:47:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 44779 invoked by uid 89); 12 Jun 2017 18:47:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=bears, Hx-languages-length:2236, reserved X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 18:47:53 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id B88B810AF07; Mon, 12 Jun 2017 14:47:55 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: "Maciej W. Rozycki" Subject: Re: [PATCH] Look for FIR in the last FreeBSD/mips floating-point register. Date: Mon, 12 Jun 2017 18:47:00 -0000 Message-ID: <1648023.dfXdf8hDrr@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20170531165803.50633-1-jhb@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00353.txt.bz2 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