Mail Archives: djgpp-workers/2000/05/20/16:38:19
> Date: Thu, 18 May 2000 17:04:04 +0200
> From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
>
> I send the source code of a very simple C program that should this bug
>
> The source follows Eli's restriction's that the FPU must be reset
> inside the signal handler but when run on a Pentium II 200 MHz (non MMX)
> under Win95 I still get a nonzero overridecount meaning that a
> second exception is sometimes raised inside the signal handler itself.
I can confirm these symptoms: on Windows 98, I get about 0.01% of
signals inside the signal handler.
> This behavior is documented in the Intel docs, that say the
> the FPU status word should be reset before resetting the IO port.
Please tell where exactly do you see this in the Intel docs, I'm not
sure I understand the issue from this single sentence.
Right now, it looks like the signals you get inside the signal handler
come from outside the program. I'm guessing that they happen because
some other piece of Windows software that works in parallel to your
program issues FP instructions, and your program gets Int 75h that it
didn't deserve.
Note that the low-order byte of the FPU status word is zero when these
extra signals are delivered. This alone should tell that those are
fake signals, not originating from your program that divides by zero.
I changed your signal handler as shown below, and the extra signals
seem to be effectively ignored, they do not cause any abnormal
behavior outside the handler. Perhaps you could do something similar
in your Pascal support routines. For example, you could ignore those
signals.
void
fpesig (i)
int i;
{
void (*oldFPE)(int) = signal (SIGFPE, SIG_IGN);
fpustate=_clear87();
if ((fpustate & 0xff) != 0)
level++;
signal (SIGFPE, oldFPE);
longjmp(t,1);
}
The two lines which set SIGFPE to SIG_IGN are just due to paranoia:
the trick with ignoring signals whose exception bits are all reset
works even if I remove those two lines.
- Raw text -