Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jan 2002 18:14:36 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Nate Williams <nate@yogotech.com>
Cc:        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:  <20020111174631.E485-100000@gamplex.bde.org>
In-Reply-To: <15421.49628.630456.688977@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2002, Nate Williams wrote:

> > > Why is reporting a SIGFPE considered broken?  This is a valid exception,
> > > and it should be reported.
> >
> > Because the SIGFPE is for the broken context-switching code and not for
> > the program.
>
> Ok, let's try again.  How can I make sure that a SIGFPE that occur due
> to a FPU operation is properly reported using fsave/frestor?

The set of such proper reports is null, so it is easily generated by not
using fsave (sic) or frstor.

> (I've asked this before, but apparently not in a way that made sense.)
>
> Here's a snippet again.
>
>  	fldz
>  	fld1
>  	fdiv %st,%st(1)		# 1.0 / 0.0 (should cause a SIGFPE exception)
>  	fsave #fooLocation
>         // Mumble mumble other code to choose a new thread
>  	frstor #barLocation
>
> Questions
>
> * Would 'thread 1' get a SIGFPE before the fsave instruction?  (Yes, No, maybe)

Only in broken cases.

> * If above is maybe, would it get the SIGFPE after a frstor #fooLocation?

No, because the frstor would never be reached (unless the SIGFPE handler
is much smarter than the above code).  The above code uses fsave to shoot
itself in the foot.  A SIGFPE occurs on the `wait' instruction which is
part of fsave.

If the fsave is corrected to fnsave, then the frstor will be reached in
non-broken cases, and the frstor will complete in all cases and will
not cause a SIGFPE in non-broken cases.

> * If answer to both is NO, how do I make sure that the context of the
>   fdiv receives a SIGFPE?  Can I use a different operation?  Can I add
>   instructions to cause this to work correctly?

Switch back to the context of the fdiv and let it execute instructions
in the normal way.  The SIGFPE will be delivered (if the division by
zero exception is not masked) on the next non-control FPU instruction
or wait instruction.  (This is for the non-broken case; in the broken
case you normally get a SIGFPE some fairly unpredictable time later,
e,g., while another thread or the kernel is executing; the SIGFPE must
somehow be ignored if it occurs for another context.  Don't worry about
this, since 386's are now rare.)

Bruce


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?20020111174631.E485-100000>