Date: Sat, 13 Nov 1999 11:24:39 -0700 From: Nate Williams <nate@mt.sri.com> To: Bruce Evans <bde@zeta.org.au> Cc: Nate Williams <nate@mt.sri.com>, Marcel Moolenaar <marcel@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <199911131824.LAA22696@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9911132009430.19572-100000@alphplex.bde.org> References: <199911130611.XAA21626@mt.sri.com> <Pine.BSF.4.10.9911132009430.19572-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. Great, thanks for the clarification... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911131824.LAA22696>