From owner-freebsd-hackers Sun Nov 19 16:27:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA16295 for hackers-outgoing; Sun, 19 Nov 1995 16:27:19 -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 QAA16287 for ; Sun, 19 Nov 1995 16:27:16 -0800 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id LAA25969 for hackers@FreeBSD.org; Mon, 20 Nov 1995 11:05:37 +1100 (EST) Message-Id: <199511200005.LAA25969@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 AA14860; Mon, 20 Nov 1995 11:08:52 +1100 From: John Birrell Subject: Re: int type in jmpbuf To: bde@zeta.org.au Date: Mon, 20 Nov 1995 11:08:52 +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 > >>typedef struct { >> char _jb0[_THE_FULL_SIZEOF_JMP_BUF]; >>} jmp_buf[1]; > >The latter is only guaranteed to be aligned on 1-byte boundaries. And it needs to be aligned so that the asm code can access it? >It's supposed to be opaque to stop that :-). Or was it opaque 'cause the only thing that accessed it was asm code which couldn't use a structure anyway? Would it be evil if it were _not_ opaque under FreeBSD? >You should copy setjmp.S >and adapt it. Note that it isn't possible to do preemptive context >switching for threads using only setjmp() - setjmp() doesn't preserve >all of the floating point state in FreeBSD. I don't agree with this. gcc under FreeBSD appears to re-load floating point "registers" after a function call (like setjmp). This means that setjmp/longjmp don't need to save the floating point state. When a signal occurs, though, the floating point state is not saved. [We think it should be saved. Is there anything that says that floating point calculations in a signal handler can ruin your whole day?! 8-)]. This is true of FreeBSD and NetBSD/i386, but it is _not_ true of NetBSD/Alpha which saves floating point registers routinely. Preemptive context switching in user-space threads under FreeBSD needs to save the floating point state when entering the scheduler from the signal handler. Before calling sigreturn to re-start an interrupted thread (as opposed to one that was simply context switched using setjmp), the floating point state is restored. This means that the behavio[u]r of a signal handler under a threaded program will not corrupt the floating point state of a program as it will with a non-threaded program. > >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