From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 06:59:48 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 5F94F106564A for ; Wed, 18 Jul 2012 06:59:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id E26CB8FC14 for ; Wed, 18 Jul 2012 06:59:47 +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 mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6I6xc1f004698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 16:59:39 +1000 Date: Wed, 18 Jul 2012 16:59:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> Message-ID: <20120718153554.O2195@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@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 06:59:49 -0000 On Wed, 18 Jul 2012, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 02:36:16PM +1000, Bruce Evans wrote: >> On Wed, 18 Jul 2012, Konstantin Belousov wrote: > ... >>> 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() could be implemented like this for amd64 only: Similarly for i386? > diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h > index 22cbbe2..3417c52 100644 > --- a/sys/amd64/include/pcb.h > +++ b/sys/amd64/include/pcb.h > @@ -144,6 +144,17 @@ void makectx(struct trapframe *, struct pcb *); > int savectx(struct pcb *) __returns_twice; > void resumectx(struct pcb *); > > +static __inline __pure2 struct pcb * > +__curpcb(void) > +{ > + struct pcb *pcb; > + > + __asm("movq %%gs:%1,%0" : "=r" (pcb) > + : "i" (offsetof(struct pcpu, pc_curpcb))); pc_curpcb is only a pointer, so there is no need for pcb.h to be used (any more than proc.h is neaded for __curthread()). I think this can go in machine/pcpu.h next to __curthread(). Or machine/cpuinfo can provide the an alternative to PCPU_GET() without __volatile and sys/pcpu.h can do this. __curthread() avoids a dependency on sys/pcpu.h by hard-coding the offset of pc_curthread as 0. This hack seems to be unnecessary, Including machine/pcpu.h without going through sys/pcpu.h should be an error. This error is only in a few low tier files: - i386/xen/pcpu.h: this bogusly includes machine/pcpu.h after already including sys/cpu.h - mips/cavium/octeon_machdep.c - mips/cavium/uart_dev_oct16550.c - powerpc/include/platform.h - xen/evtchn.h. xen code is horrible. In i386/include/xen/xen_os.h, as part of this file's namespace pollution, it claims to include sys/time.h for pcpu.h. But actually sys/time.h only provides moderate namespace pollution that doesn't include pcpu.h. It is another style bug to include sys/time.h directly. sys/time.h is standard namespace pollution in sys/param.h in the _KERNEL case. So amd64 can apparently safely put this function in machine/pcpu.h. i386 might have to untangle the xen pollution. Other arches aren't directly affected, since they don't have npx. I wondered if they even had curpcb (if not then pc_curpcb should be in the MD fields). Grep shows that they have considerable variation and messes. At lease ia64 doesn't use the "MI" pc_curpcb. There is similar variation and messes for pcpup. > + return (pcb); > +} > +#define curpcb (__curpcb()) > + > #endif > > #endif /* _AMD64_PCB_H_ */ > diff --git a/sys/sys/user.h b/sys/sys/user.h > index accb7c3..ab1c7a7 100644 > --- a/sys/sys/user.h > +++ b/sys/sys/user.h > @@ -35,6 +35,7 @@ > #ifndef _SYS_USER_H_ > #define _SYS_USER_H_ > > +#include Too much namespace pollution for me. > #include Putting the definiton in machine/pcpu.h should avoid changing the prerequistes for machine/pcb.h. > #ifndef _KERNEL > /* stuff that *used* to be included by user.h, or is now needed */ > > Please note the location in pcb.h an not in machine/pcpu.h, where it > cannot work for technical reasons (struct pcpu is not defined yet). Not applicable -- see above. > This should be committed separetely, together with the pass over amd64/ > to convert PCPU_GET(curpcb) into curpcb(). > > Do you agree with committing the PR fix as is and adding the curpcb() later ? > And removing fnclex() later (it seems I convinced enough for its removal). OK. Bruce