Date: Sat, 13 Nov 1999 15:20:35 +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.9911131502310.19037-100000@alphplex.bde.org> In-Reply-To: <199911121711.KAA19367@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > By reseting the FPU with fninit, we *lose* much of the state, we in our > > > code we must restore the state (which we stored before the call to > > > sigsetjmp with fsave/fwait). > > > > fninit lose some current state, but nothing related to the state at the > > time of the sigsetjmp(). JDK apparently needs to restore the state at > > the time of the setjmp(). > > Right. What else would you restore if not the state at the time of the > setjmp? You would restore as necessary to prevent clobbering of local variables that are stored in registers at the time of the longjmp. In our i386 implementation, there are no such floating point variables, but the implementer of longjmp() should be aware of this. Any such integer and pointer variables are clobbered, as permitted by the C standard. Some implementations of longjmp() do extra work to support broken programs that don't expect this. > > The comment seems to be misleading. It > > should probably say "FreeBSD's siglongjmp() doesn't restore the FPU to > > its state at the time of the sigsetjmp(), so we restore it here". > > What other state would you restore if not the state at the time of the > sigsetjmp? You would set (not restore) to a default state. That's what fninit does. 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.9911131502310.19037-100000>