From: Ralf Baechle <ralf@oss.sgi.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux: Report the faulting FPU instruction
Date: Tue, 27 Nov 2001 12:13:37 +1100 [thread overview]
Message-ID: <20011127121337.E2525@dea.linux-mips.net> (raw)
In-Reply-To: <Pine.GSO.3.96.1011126160822.21598N-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 04:28:34PM +0100
On Mon, Nov 26, 2001 at 04:28:34PM +0100, Maciej W. Rozycki wrote:
> I believe it's desireable to point to the faulting instruction upon an
> FPU trap and not the following one. Why? First, the FPU restores the
> state from before attempting to exectute the instruction. Second, with
> the current approach state is lost -- consider instructions in branch/jump
> delay slots. Third, erroneous execution is possible if SIG_FPE's handler
> is set to "ignore" by mistake.
>
> The following patch implements the described approach. It should not
> affect standard handlers which use setjmp()/longjmp(), but it should
> enable a smarter interpreting handler or just better diagnostics. Both
> the hardware and the emulator are handled. Tested successfully with gdb
> on an R3k, an R4k and the emulator.
The problem you found in the FPU emulator is a fairly generic one. We
got other exception handlers which in error case will still skip over
the instruction. What also isn't handled properly is the case of sending
a signal to the application. In such a case sigreturn() should do the
the compute_return_epc() thing ...
Ralf
next prev parent reply other threads:[~2001-11-27 4:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-26 15:28 [patch] linux: Report the faulting FPU instruction Maciej W. Rozycki
2001-11-27 1:13 ` Ralf Baechle [this message]
2001-11-27 13:20 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011127121337.E2525@dea.linux-mips.net \
--to=ralf@oss.sgi.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.