From owner-cvs-all Sat Nov 13 1:32:23 1999 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CAD1F14A25; Sat, 13 Nov 1999 01:32:16 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from p46-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id UAA27717; Sat, 13 Nov 1999 20:38:24 +1100 Date: Sat, 13 Nov 1999 20:32:00 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Nate Williams Cc: Marcel Moolenaar , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <199911130611.XAA21626@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > You would restore as necessary to prevent clobbering of local variables > > that are stored in registers at the time of the longjmp. > > Umm, I thought Marcel's comment was that we would be now supporting > floating point context. In that case, then we should restore the FP > state, shouldn't we? What else would be necessary to support FP state? Supporting floating point in signal handlers will allow less restoring/ resetting of FP state in setjmp()/longjmp(). Now, on i386's, the FP state is undefined in signal handlers, and to make longjmp() from signal handlers sort of work we reset to a default state, except we restore the FP control word to its value at the time of the setjmp(). When the state is set to a default for signal handling, the reset/restore will be unnecessary. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message