linux-mips
[Top] [All Lists]

Re: Unexpected behaviour when catching SIGFPE on FPU-less system

To: Shane McDonald <mcdonald.shane@gmail.com>
Subject: Re: Unexpected behaviour when catching SIGFPE on FPU-less system
From: "Kevin D. Kissell" <kevink@paralogos.com>
Date: Tue, 04 May 2010 14:52:05 -0700
Cc: linux-mips@linux-mips.org
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=paralogos.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=AcCaa/e/Tmr3PuLkyBa92NB5xPEyotIvu7OGlhxT/z2wFW5sx8utmcYlkRHFyOVqpAI3xLAZeimOtpakCjKeL70AiLCV3ZBBGSHz4h29gKnMlHA+iFfr2kBrXCiKOaye;
In-reply-to: <4BE0479E.6060506@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1O8lDn-0000Sk-86@localhost> <4BDF366E.5000501@paralogos.com> <k2hb2b2f2321005031843l87f39f36h960153cae3ec5020@mail.gmail.com> <4BDF8092.1060401@paralogos.com> <n2pb2b2f2321005032049h56cd72ceh3ac7120c547b59c5@mail.gmail.com> <n2rb2b2f2321005032135ze807a2aft8811a7937288de53@mail.gmail.com> <m2rb2b2f2321005032356j854934d9v42a9e50683b085a8@mail.gmail.com> <4BE00207.6030506@paralogos.com> <m2zb2b2f2321005040556g80eed954p7ac11e2cd05921c6@mail.gmail.com> <4BE0479E.6060506@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.24 (X11/20100317)
Kevin D. Kissell wrote:
Shane McDonald wrote:
In the following chunk of code from cp1emu.c:
[snip]
value gets set to an initial value of 0x400, and ctx->fcr31
comes in with an initial value of 0x8420.
By the time we hit the if statement around the return SIGFPE, ctx->fcr31
has been set to 0x8400, not the 0x400 I implied.
Ah, well that would rather change things, and you *would* get an
exception there.  As written, the code doesn't seem to allow the pending
exception (.._X) bits to be cleared by the CTC.
Nevertheless, that's not the problem.
Maybe it is.
OK, sorry to have been looking at this in fits and starts, but indeed, I submit that the bug is indeed in that ctc_op: case of the emulator. The Cause bits (17:12) are supposed to be writable by that instruction, but the CTC1 emulation won't let them be updated by the instruction. I don't have the means to generate, test, and submit a proper patch, but I think that actually if you just completely removed lines 387-388:


value &= (FPU_CSR_FLUSH | FPU_CSR_ALL_E | FPU_CSR_ALL_S | 0x03);
ctx->fcr31 &= ~(FPU_CSR_FLUSH | FPU_CSR_ALL_E | FPU_CSR_ALL_S |0x03);

Things would work a good deal better. At least, it would be a more accurate emulation of the architecturally defined FPU. If I wanted to be really, really pedantic (which I sometimes do), I'd also protect the reserved bits that aren't necessarily writable, so we'd nuke those two lines, then have

/* Don't write reserved bits, and convert to ieee library modes */
ctx->fcr31 = (value & ~0x1c0003) | ieee_rm[value & 0x3];

Note that I've changed the existing |= to a direct assignment here.

Hope this helps.

/K.

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