cvs commit: src/sys/i386/include npx.h src/sys/i386/i386 vm_machdep.c src/sys/i386/isa npx.c

David Xu davidxu at
Sat May 27 23:44:51 PDT 2006

On Sunday 28 May 2006 13:15, Bruce Evans wrote:
> 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. 

No, pthread_create is not fork, they are different.
I think you misunderstood x86's float-pointing status and POSIX float
point environment.
POSIX defined following environment flags:

which when implemented by x86, they are in control word, status word
is nothing to do with new threads, no pending exceptions should be
inherited by new thread.

> 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. 
This was already fixed in my second commit.

> 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.
Well, I am trying to do things correctly, fix bugs and then optimize it, 
rather than do nothing, and leave the bug there.

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

More information about the cvs-src mailing list