From owner-freebsd-current  Thu Aug 27 03:55:36 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA23542
          for freebsd-current-outgoing; Thu, 27 Aug 1998 03:55:36 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23536
          for <current@FreeBSD.ORG>; Thu, 27 Aug 1998 03:55:33 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id UAA18772;
	Thu, 27 Aug 1998 20:54:37 +1000
Date: Thu, 27 Aug 1998 20:54:37 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199808271054.UAA18772@godzilla.zeta.org.au>
To: bde@zeta.org.au, cracauer@cons.org, current@FreeBSD.ORG,
        luoqi@watermarkgroup.com, shocking@prth.pgs.com
Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> 2) if the SIGFPE was for an FP  operation, then the FP operatation will be
>>    restarted.  The kernel has cleared the trap-pending flag before delivering
>>    the SIGFPE to the application, and on i386's traps are delivered to the
>>    kernel on the the first non-control FP operation after the one that
>>    caused the exception, so it is certain that the restarted FP operation
>>    won't trap; it may cause an exception which will be delivered to the
>>    kernel on the next non-control FP operation.
>
>I'm not able to reproduce this behaviour. I wrote a short test program
>that runs like this:

It's easiest to reproduce it using assembler code - fill up the stack
with near-garbage using 8 fldz's and then attempt to clean up the stack
using 8 fdivp's.  The fdivp's will have no effect except to generate
FP exceptions, but if a compiler had generated them, it would expect
the stack to be clean at the end.

I wrote the assembler code.  Run it under gdb and look at the FP
state using `info float'.  Homework: explain why this generates
only 6 SIGFPE's although it divides by 0.0 by 0.0 8 times.

Bruce

#include <floatingpoint.h>
#include <signal.h>

int
main(void)
{
	/* I'm too lazy to set up signal handler.  Use gdb to watch signals. */
	signal(SIGFPE, SIG_IGN);

	/* Ensure a SIGFPE for 0.0/0.0. */
	fpsetmask(FP_X_INV);

	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fldz");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");
	asm("fdivp %st(0)");

	return (0);
}

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message