[Top] [All Lists]

Re: FCSR Management

To: "Kevin D. Kissell" <>
Subject: Re: FCSR Management
From: Jun Sun <>
Date: Tue, 24 Sep 2002 10:37:03 -0700
In-reply-to: <008801c2639f$385b1b80$10eca8c0@grendel>; from on Tue, Sep 24, 2002 at 09:51:18AM +0200
Original-recipient: rfc822;
References: <008801c2639f$385b1b80$10eca8c0@grendel>
User-agent: Mutt/1.2.5i
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...


<Prev in Thread] Current Thread [Next in Thread>