In looking at some anomalous behavior on another software
platform, I checked the current MIPS/Linux kernel sources
and I wonder if we don't have yet another FP context problem
lurking under the surface.
On most, if not all, MIPS CPUs with integrated FPUs,
the act of writing a value to the FP CSR (Control and
Status Register, fcr31) which has the "E" bit, or any matching
pair of Enable/Cause bits for the V/Z/O/U/I IEEE exceptions
set will trigger a floating point exception. In the case of
the Unimplemented Operation exception (the "E" bit),
the emulator is invoked and all of the Cause bits are cleared
in the context before user execution is resumed. In the
case of other FP exceptions, the default behavior is to
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.
Am I missing something, or is this a problem?
Regards,
Kevin K.
