Date: Sat, 13 Nov 1999 20:32:00 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nate Williams <nate@mt.sri.com> Cc: 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: <Pine.BSF.4.10.9911132009430.19572-100000@alphplex.bde.org> In-Reply-To: <199911130611.XAA21626@mt.sri.com>
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. Bruce 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?Pine.BSF.4.10.9911132009430.19572-100000>