Date: Sat, 7 Apr 2012 12:57:29 -0400 From: David Schultz <das@FreeBSD.ORG> To: Tijl Coosemans <tijl@FreeBSD.ORG> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r232275 - in head/sys: amd64/include i386/include pc98/include x86/include Message-ID: <20120407165729.GA2737@zim.MIT.EDU> In-Reply-To: <201203022231.43186.tijl@freebsd.org> References: <201202282217.q1SMHrIk094780@svn.freebsd.org> <201203012347.32984.tijl@freebsd.org> <20120302132403.P929@besplex.bde.org> <201203022231.43186.tijl@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 02, 2012, Tijl Coosemans wrote: > Thanks, that was quite informative. C11 does say something about the > FP env and signals now though: > > ``When the processing of the abstract machine is interrupted by receipt > of a signal, the values of objects that are neither lock-free atomic > objects nor of type volatile sig_atomic_t are unspecified, as is the > state of the floating-point environment. The value of any object > modified by the handler that is neither a lock-free atomic object nor > of type volatile sig_atomic_t becomes indeterminate when the handler > exits, as does the state of the floating-point environment if it is > modified by the handler and not restored to its original state.'' > > This means a signal handler must not rely on the state of the FP env. > It may install its own FP env if needed (e.g. FE_DFL_ENV), but then it > must restore the original before returning. This allows for the > rounding mode to be silently modified for integer conversions for > instance. > > If longjmp is not supposed to change the FP env then, when called from > a signal handler, either the signal handler must install a proper FP > env before calling longjmp or a proper FP env must be installed after > the target setjmp call. Otherwise the FP env is unspecified. There are two reasonable ways to handle the floating point control word. FreeBSD treats it as a register, resetting it on signal handler entry and restoring it on longjmp or signal handler return. Virtually every other OS (e.g., Linux, NetBSD, Solaris) treats it as global state, leaving it up to the signal handler to preserve it as needed. Both approaches have their merits. FreeBSD's approach provides better semantics. Library functions, round-to-integer on most CPUs, and other things may temporarily change the rounding mode. Most programmers don't think about that, but on Linux, if an async signal were delivered at the wrong time and did a longjmp, the rounding mode would be in an unexpected state. Most programmers don't think about that; even a program that never changes the rounding mode explicitly could wind up in round-to-zero mode after jumping out of a signal handler. The main advantage of the alternative approach is that it avoids the overhead of saving and restoring the floating point control word. Many programs don't even use floating point, and the efficiency is important for programs that use longjmp frequently, e.g., to implement exceptions. Either way, note the importance of being consistent: If the FP env gets clobbered automatically on entry to a signal handler, then longjmp must restore what the application had before. Personally, I'm not opposed to changing both signal handlers and longjmp to match what the rest of the world does, but this isn't just about the mxcsr, as suggested previously. By the way, this commit is a good example of how getting rid of duplication can actually make things more confusing. The code is the same on both amd64 and i386 now, but it means different things. Furthermore, each platform has a different setjmp implementation, so if someone has to change jmpbuf on one of them in the future, they have to worry about breaking the other as well. This is illustrated by the fact that this very commit silently changed the i386 ABI by increasing the size of struct jmpbuf.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120407165729.GA2737>