Date: Mon, 20 Nov 1995 17:33:20 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cimaxp1!jb@werple.net.au Cc: hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: int type in jmpbuf Message-ID: <199511200633.RAA01704@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>>Would it be evil if it were _not_ opaque under FreeBSD? >> >>It would require more support (something like sys/i386/i386/genassym.c >>to keep the asm offsets in sync with the C offsets). >Of course the asm offsets are "cast in stone" because they affect >compatibility. I just thought that if jmp_buf contained a structure it could >reflect things the way they are... so although the asm offsets _could_ be >maintained, they don't _need_ to be. Actually, the offsets can be changed easily since the structs are opaque. It is only necessary for the setjmp/longjmp pair in the (possibly shared and changing every day) library to agree with each other. The sizes of the objects are harder to change. >>POSIX.1 (3.3.1.3(3)(b)) seems to require saving the FP state although >>ANSI C doesn't. >ANSI C says that you can do a longjmp from a signal handler. This implies that >FP state is restored to that when setjmp was called (and as you've said, this >is with the FP stack empty). ANSI C only requires longjmp() to work for synchronous signals (i.e., for those invoked by raise() and abort()). It would be sufficient to preserve the FP control word and the pending exception bits for sync signals. FreeBSD does this and clears the FP stack so that longjmp works from all signal handlers (except when there is a pending exception and the machine has the i387 coprocessor bug). >>You'll have to worry about the i387 (separate) coprocessor bug as in the >>kernel: fnsave/frstor may trigger an FPU trap that is not supposed to >I'm not sure if there is anything I can do about this, because the scope of >the user-space threads work is such that it has to work with the kernel the Something involving a SIGFPE handler might work. Ugh. >The MIT pthread code does an fsave without a fwait to save the FP state. >Is this valid? It looks like gcc generates the same code for fsave as fnsave. It's important to _not_ have an fwait. On x87's later than the 8087 (or maybe the 80287) and on x86's later than the 386, synchronization between FPU instructions is automatic and an fwait does little more than trigger any pending FPU exception, which you don't want while context switching. gas uses confusing mnemonics for the no-wait vs the `wait' instructions: intel gas right ----- --- ----- fnsave fnsave or fsave fnsave fsave fwait; fnsave or fsave fwait; fnsave `fwait; fnsave' is not useful except for the 8086. `fnsave; fwait' may be more useful. Old manuals say to use fwait to synchronize between FPU instructions and memory accesses, but this is apparerently a bug in the manuals. Synchronization is automatic at least for x86's later than the 386, at least when the cpu accesses the memory (I'm not sure about DMA). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511200633.RAA01704>