Date: Thu, 10 Jan 2002 09:22:17 -0700 From: Nate Williams <nate@yogotech.com> To: Dan Eischen <eischen@vigrid.com> Cc: Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15421.49081.206713.580230@caddis.yogotech.com> In-Reply-To: <3C3D8C47.D3B11B87@vigrid.com> References: <20020110091018.0788A38CC@overcee.netplex.com.au> <3C3D8C47.D3B11B87@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > FWIW, this is no longer the case. On all current CPUs, there are a whole > > stack more registers. The context save buffer is 512 bytes long. It isn't > > all used yet, but will be at some point in the future as long as you use > > the defined fxsave/fxrstor instructions. > > > > struct envxmm { > > u_int16_t en_cw; /* control word (16bits) */ > > u_int16_t en_sw; /* status word (16bits) */ > > u_int16_t en_tw; /* tag word (16bits) */ > > u_int16_t en_opcode; /* opcode last executed (11 bits ) */ > > u_int32_t en_fip; /* floating point instruction pointer */ > > u_int16_t en_fcs; /* floating code segment selector */ > > u_int16_t en_pad0; /* padding */ > > u_int32_t en_foo; /* floating operand offset */ > > u_int16_t en_fos; /* floating operand segment selector */ > > u_int16_t en_pad1; /* padding */ > > u_int32_t en_mxcsr; /* SSE sontorol/status register */ > > u_int32_t en_pad2; /* padding */ > > }; > > struct fpacc87 { > > u_char fp_bytes[10]; > > }; > > struct xmmacc { > > u_char xmm_bytes[16]; > > }; > > struct savexmm { > > struct envxmm sv_env; > > struct { > > struct fpacc87 fp_acc; > > u_char fp_pad[6]; /* padding */ > > } sv_fp[8]; > > struct xmmacc sv_xmm[8]; > > u_long sv_ex_sw; /* status word for last exception */ > > u_char sv_pad[220]; > > } __attribute__((aligned(16))); > > > > There are eight 10-byte registers, and eight 16-byte registers. > > > > union savefpu { > > struct save87 sv_87; > > struct savexmm sv_xmm; > > }; > > > > /* and this is what we save for userland state */ > > struct pcb { > > ... > > union savefpu pcb_save; > > }; > > > > When a userland application does a getcontext(), the kernel looks at > > fpcurthread to see if the calling process/thread/whatever has got its > > context stored in the pcb or in the live registers. There is no need to > > copy state to the FPU solely in order for the userland to save a copy. > > I think we determined that the only time we care about the FP state is > when sending a signal. Bruce stated this, but I'm not sure I agree since it's not obvious (to me anyway) that this always works when doing yield's and such which don't cause a signal to be sent. > In that case, the kernel should know how to get the FPU state and copy > it out to the context. If there are different FPU formats, there is a > flags word that can be set accordingly and the userland setcontext() > can be made to account for different floating point formats. See above. > Currently the kernel doesn't save the FPU state in the sigcontext, > but it should. Wouldn't this solve the problem? I believe so, given the comments stated on this thread. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15421.49081.206713.580230>