Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 May 2006 15:15:34 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        David Xu <davidxu@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/i386/include npx.h src/sys/i386/i386  vm_machdep.c src/sys/i386/isa npx.c
Message-ID:  <20060528134646.V19811@delplex.bde.org>
In-Reply-To: <200605280203.k4S23DfP053792@repoman.freebsd.org>
References:  <200605280203.k4S23DfP053792@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 May 2006, David Xu wrote:

> davidxu     2006-05-28 02:03:13 UTC
>
>  FreeBSD src repository
>
>  Modified files:
>    sys/i386/include     npx.h
>    sys/i386/i386        vm_machdep.c
>    sys/i386/isa         npx.c
>  Log:
>  When creating a new thread, inherit floating-point environment from
>  current thread, this is required by POSIX pthread_create document.
>
>  Revision  Changes    Path
>  1.272     +1 -0      src/sys/i386/i386/vm_machdep.c
>  1.30      +4 -0      src/sys/i386/include/npx.h
>  1.167     +30 -0     src/sys/i386/isa/npx.c

POSIX seems to require inheriting the entire environment, but this
change does extra work to disinherit everything except the control
word(s), except in the fxsr case it is missing the extra work to
disinherit the status bits in the mxcsr.  BTW, setjmp()/longjmp() has
much larger bugs in this area (they preserve the FP control word but
don't even know about mxcsr even on amd64 where mxcsr is primary, so
they they mess up both the control and status in mxcsr).

This change also does a lot of work to determine the control word(s),
and a lot of work to use the old control word(s) even if the old control
word(s) are the default.  The case where the old thread has the default
(!PCB_NPXINITDONE) FP state should be optimized by doing nothing except
checking for this case.  Otherwise, if preserving only the control
word(s) is required, some optimizations are possible with extra
complications (*).  Otherwise (when the whole environment needs to be
preserved then it is simplest and fastest to copy the entire state
(the data registers may need to be cleared for security, but not doing
so would give less important leaks than already exist).  Then the new
interface wouldn't be needed.

(*) The control word(s) can be obtained much more efficiently than using
npxgetregs().  In most cases the control word(s) won't have changed from
their default and nothing needs to be done except for checking that they
haven't changed.  OTOH, the FP environment contains status words which
have changed in most cases, so this sort of optimization won't work if
the FP environment must be inherited.

This change has some style bugs (with highest density in npx.h).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060528134646.V19811>