On Tue, Sep 24, 2002 at 09:51:18AM +0200, Kevin D. Kissell wrote: > 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? > FPE exceptions, actually almost all exceptions, are cleared before their handlers are invoked. See kernel/entry.S and look for BUILD_HANDLER(). Those macro defines are really mind-twisting and usually don't show up on grep radar... Jun
