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>