From owner-freebsd-hackers Sun Nov 19 21:45:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA10365 for hackers-outgoing; Sun, 19 Nov 1995 21:45:27 -0800 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA10359 for ; Sun, 19 Nov 1995 21:45:21 -0800 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id PAA08841 for hackers@FreeBSD.org; Mon, 20 Nov 1995 15:57:03 +1100 (EST) Message-Id: <199511200457.PAA08841@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA07484; Mon, 20 Nov 1995 16:01:08 +1100 From: John Birrell Subject: Re: int type in jmpbuf To: bde@zeta.org.au Date: Mon, 20 Nov 1995 16:01:07 +1100 (EST) Cc: hackers@FreeBSD.org, jb@cimlogic.com.au X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk >>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. >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). >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 >occur until the next _non control_ FPU instruction. The kernel protects >itself by masking the traps until user mode is resumed, but the >transparency of the context switch is lost. 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 way it is. I can't see a way of using the existing syscalls to get the kernel to call the npxsave function (which has the trap masking) and return this to the process. And I can't mask traps in user-space. 8-(. 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. > >Bruce -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137