Re: FCSR Management

[Jun Sun <jsun@mvista.com>]

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