Date: Wed, 9 Jan 2002 11:14:11 -0700 From: Nate Williams <nate@yogotech.com> To: Bruce Evans <bde@zeta.org.au> Cc: Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, <arch@FreeBSD.ORG> Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15420.34931.201187.449640@caddis.yogotech.com> In-Reply-To: <20020109192223.H7698-100000@gamplex.bde.org> References: <15419.13318.535192.666599@caddis.yogotech.com> <20020109192223.H7698-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > fldz > > > fld1 > > > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > > > # but no trap yet > > > fnstsw %ax # no trap yet since this is control instruction > > > fnclex # forget about exception; no trap at all since > > > # we did only control instructions after the > > > # one that cause the exception > > > > > > > > It is especially wrong for fnsave in context switches because it > > > > > causes the signals in the context of the context switcher instead of > > > > > in the context of the thread that caused the exception. > > > > > > > > Which signals are you refering to? > > > > > > The SIGFPE that you get for `wait'. > > > > So, when is SIGFPE going to be triggered above, since it appears to be > > masked by using fnstw vs. fstw. > > When the above is interrupted by a signal, and the signal handler wants > to switch to another thread, and erroneously saves the context using > fsave instead of fnsave. Assuming I used followed things up with 'fnsave', will the exception be triggered by a frstor, and thus the exception will be correctly reported by the thread triggering the excpetion? > > In other words, how do I actually make sure that I receive the > > exception/trapf for FP errors? > > Let the thread (appear to) continue normally by never triggering a trap > for the exception if you switch its context. Using fnsave/frstor > accomplishes this, except on broken (old) systems where fnsave traps anyway. Is this broken hardware systems, or broken software systems? (In other words, does "broken (old)" imply a bug in hardware or software?) > The kernel has lots of complications to minimise the damage from this. > It doesn't seem to be possible to prevent the spurious trap as require > to not break instruction sequences like the above, but it is necessary > to make the trap appear to occur in user context and not in kernel > context where it actually occurs. Great. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15420.34931.201187.449640>