Date: Thu, 10 Jan 2002 07:42:47 -0500 From: Dan Eischen <eischen@vigrid.com> To: Peter Wemm <peter@wemm.org> Cc: 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: <3C3D8C47.D3B11B87@vigrid.com> References: <20020110091018.0788A38CC@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> 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. 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.
Currently the kernel doesn't save the FPU state in the sigcontext,
but it should. Wouldn't this solve the problem?
--
Dan Eischen
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?3C3D8C47.D3B11B87>