From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 04:36:20 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03CB91065674 for ; Wed, 18 Jul 2012 04:36:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8D22E8FC0A for ; Wed, 18 Jul 2012 04:36:19 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6I4aGxT001857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 14:36:17 +1000 Date: Wed, 18 Jul 2012 14:36:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120718035220.GO2676@deviant.kiev.zoral.com.ua> Message-ID: <20120718140523.X1862@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 04:36:20 -0000 On Wed, 18 Jul 2012, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote: >> OK. Also, you can tell instruction that faulted, provided there are >> no spurious faults. I think spurious faults can only occur for IRQ13 >> exception handling which was never supported for amd64 and is no longer >> supported for i386. My old test program that is broken by not clobbering >> the status was mainly for finding and fixing such spurious faults. >> I never owned an i387 or i486SX and had to break i486 exception handling >> to test IRQ13. > 486SX+487 never used irq13 as well, since 487 was the 'full' DX package, > which turned off SX socket. The 487 is still a separate package. I thought it had to use IRQ13 to communicate with the 486SX since the NE# (?) and ERR# (?) pins only work for a single package. Do they actually work for the separate package? >> Just noticed another style/efficiency bug: this should use curpcb, >> not curthread->td_pcb. I don't like the curpcb global, but as >> long as it exists, it should be used. Every time I looked at >> removing this global, it seemed better to keep it. C code can >> easily use curthread->td_pcb instead of curpcb, and this is faster >> if curthread is cached. But CURPCB is easier to use in asm. > I changed to use curpcb (its use is indeed mainly for asm context switch > code). I do want to use pcb_save though, see below. >> ... >> I now quote your newer patch for the fputrap_x87() cleanup: >> >>> @@ -531,8 +534,9 @@ static char fpetable[128] = { >>> * solution for signals other than SIGFPE. >>> */ >>> int >>> -fputrap() >>> +fputrap_x87(void) >>> { >>> + struct savefpu *pcb_save; >> >> No need for this before or after. Let the compiler cache it. Just use >> curpcb now. > The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that > compiler is not allowed to cache the accesses, since there is __asm > __volatile expression to indirect through %gs-prefixed read. Fix curpcb then. curthread was de-pessimized to use __pure2 and to not use __volatile. I could never this to work to cache curthread when I ried it, but it apparently works in -current. curpcb is no more fragile than curthread without the __volatile. Especially in fputrap*() where they are accessed under critical_enter(). They are switched at the same time. Any locking in pcpu access functions for them would be useless, since it goes away when the function returns. Apparently they are sufficiently locked by the logic of the code (unlike fpucurthread, which requires the critical_enter()). curthread is the only pcpu variable important enough to have a special access function in amd64 pcpu.h. curpcb is not very important, but spelling it curpcb = __curpcb() instead of PCPU_GET(curpcb) is simpler for clients as well as faster. > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > ... OK except for the curpcb caching and the fnclex removal, which should be done separately. Speaking of ABI changes, the default i386 FP rounding precision (and collateral gcc bugs) should have been changed from 53 to 64 bits a few years ago, after libc (printf) and libm started working around the old gcc precision bugs well enough. That will be really painful for compat code. Bruce