[patch] linux: Report the faulting FPU instruction

[patch] linux: Report the faulting FPU instruction

[Maciej W. Rozycki]

Hello,

 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. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.14-20011123-fpu-epc-0
diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c
--- linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c	Wed Nov 21 05:26:46 2001
+++ linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c	Sun Nov 25 13:25:06 2001
@@ -497,9 +497,6 @@ asmlinkage void do_fpe(struct pt_regs *r
 		return;
 	}
 
-	if (compute_return_epc(regs))
-		return;
-
 	force_sig(SIGFPE, current);
 	printk(KERN_DEBUG "Sent send SIGFPE to %s\n", current->comm);
 }
diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c
--- linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c	Sun Oct 14 04:26:36 2001
+++ linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c	Sun Nov 25 13:29:30 2001
@@ -1721,6 +1721,9 @@ int fpu_emulator_cop1Handler(struct pt_r
 		/* but if epc has advanced, then ignore it */
 		sig = 0;
 
+	if (sig)
+		xcp->cp0_epc = prevepc;
+
 	return sig;
 }
 

Re: [patch] linux: Report the faulting FPU instruction

[Ralf Baechle]

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

Re: [patch] linux: Report the faulting FPU instruction

[Maciej W. Rozycki]

On Tue, 27 Nov 2001, Ralf Baechle wrote:

> 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 ...

 Well, with break/trap 6/7 I have already noticed exception handlers tend
to call compute_return_epc() unnecessarily.  I shall be cleaning the code
gradually as time passes by...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +