Date: Fri, 11 Jan 2002 15:56:31 -0700 From: Nate Williams <nate@yogotech.com> To: Bakul Shah <bakul@bitblocks.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15423.28063.92751.501022@caddis.yogotech.com> In-Reply-To: <200201112251.RAA07625@repulse.cnchost.com> References: <3C3F690B.9A5959A1@mindspring.com> <200201112251.RAA07625@repulse.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I am not prepared to speculate on the use of FP & SSE > > > registers at this point except for one thing: an FP exception > > > *must* be delivered to whichever thread caused it. Any bugs > > > in SIGFPE delivery is a separate discussion! > > [ ... ] > > > > Cool. We are all in agreement on this: the thread that > > caused it is the thread that executes an FPU instruction > > after an error in an instruction by some FPU using thread, > > whatever thread that is. > > > > 8-p > > > > The exception signalling lags the event that was the cause > > of the exception in x86 hardware, if this wasn't clear... > > What is not clear to me is why is this relevant only now -- > whether the kernel switches threads or they are switched in > the user mode, the bug (if there is one) will bite you the > same, right? Explain it real slowly. :-) It's not any more/less relevant now. It's just that it was mostly misunderstood in the past, and since we're trying to make get/setcontext library calls, we want to make sure to get it right. According to Bruce, it may not work as we expected in the past. > I'd better readup on x86 FP.... Hopefully you're reading will be better than mine. :( 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?15423.28063.92751.501022>