Should send SIGFPE to .*

[Florian Lohoff <flo@rfc822.org>]

Hi,
i just rediscovered the kernel messages in the kern.log ...

Apr 19 20:12:41 repeat kernel: Setting flush to zero for top.
Apr 19 20:12:41 repeat kernel: Unimplemented exception for insn 46001124 at 
0x00403588 in top.
Apr 19 20:12:41 repeat kernel: Should send SIGFPE to top

This is something i not really understand - After "Setting flush to zero" the
instruction is "retried" and enters the exception again and say
"Unimplemented exception" which means - The CPU doesnt support it
and then "Simulates" this instruction in "simfp(insn)" - Until
now nothing bad has happened and these two kernel messages
should be encapsulated by a "#if DEBUG_FP_EXCEPTION" or something.

Now i get an "Should send SIGFPE to top" which i dont understand - Shouldnt
SIGFPE signal Floating Point errors (like div by zero) - As the code
gets simulated in simfp this function should be responsible for 
sending the signal if something goes wrong ?

arch/mips/kernel/traps.c

    354                 printk(KERN_DEBUG "Unimplemented exception for insn 
%08x at 0x%08lx in %s.\n",
    355                        insn, regs->cp0_epc, current->comm);
    356                 simfp(insn);
    357         }
    358 
    359         if (compute_return_epc(regs))
    360                 goto out;
    361         //force_sig(SIGFPE, current);
    362         printk(KERN_DEBUG "Should send SIGFPE to %s\n", current->comm);
    363 
    364 out:
    365         unlock_kernel();


Might it be that compute_return_epc in branch.c does not support
the mentioned instructions (FP instructions ?) and though can not
calculate the correct epc ?

Flo
-- 
Florian Lohoff          flo@rfc822.org                  +49-subject-2-change
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."iii