> On Tue, 24 Sep 2002, Kevin D. Kissell wrote:
>
> > dump core, so the user never executes again. But *if*
> > the user has registered a handler for SIGFPE, and one
> > of the IEEE exceptions occurs, I don't see where the
> > associated Cause bit is being cleared, and I would think
> > that the consequence would be that the process would
> > get into an endless loop of trapping, posting the signal,
> > restoring the FCSR from the context with the bits set,
> > and trapping again, whether or not the PC is modified
> > to avoid re-executing the faulting instruction.
>
> Obviously user code is responsible to clear the bit it acted upon in the
> saved context.
It may be obvious that someone *intended* that user code
clear the bit. But the FCSR value containing the trapping
condition seems to be saved as part of both the thread
and the signal contexts, thus (a) it could be restored as
part of the sigcontext load of the signal handler, causing
a re-entrant trap, possibly ad infinitum, and (b) will be
restored in the thread state after the execution of the
signal in any case, since we don't allow signals to have
side-effects on the FP register state, including the FCSR.
So even if the signal handler executed far enough to clear
the relevant Cause bit, it looks to me as if it would simply
be re-set the next time the thread loaded the FPU context.
I haven't seen anyone complaining about threads hanging
when SIGFPE's are being caught, so things may be working
somehow - but we may be blundering through some number
of spurious traps for no good reason before we get there.
I'll be delighted if someone on the list could point out
how the probelem is being bypassed..
Kevin K.
