Re: PROBLEM: Caught SIGFPE exceptions aren't reset
- From: Mikael Pettersson <mikpe@xxxxxxxx>
- Date: Sat, 25 Aug 2007 12:15:30 +0200
Clark Cooper writes:
[1] Caught SIGFPE exceptions aren't reset
[2]
On an i386, you can set a handler for a SIGFPE signal, and after enabling FP
exceptions with feenableexceptions(), an FP exception will cause
your handler
to be called. However after the handler returns, it is called
again with the
same FP error. Control never returns to the point after the
instruction that
caused the exception.
User error.
You cannot write working SIGFPE handlers without understanding the
underlying FP instruction set and its exception model, and being
prepared to write CPU- and OS-specific code.
In particular, on modern x86, an SSE2 FP instruction that raises
an exception will be set to restart in the resumption state.
It's up to your handler to either bypass the restart (longjmp),
or to update the resumption state so that it can be resumed without
triggering an infinite loop. Your handler can do this by masking
exceptions, changing the operands of the failed FP instruction,
or by changing the PC so that the failed instruction is skipped
(your handler may want to emulate the instruction in this case).
This is not a kernel problem.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- PROBLEM: Caught SIGFPE exceptions aren't reset
- From: Clark Cooper
- PROBLEM: Caught SIGFPE exceptions aren't reset
- Prev by Date: Re: readXs on pci*iomap-ped regions [Was: [PATCH] /drivers/char sx.c ioremap -> pci_ioremap api]
- Next by Date: Re: [PATCH -mm 2/2] Hibernation: Arbitrary boot kernel support on x86_64
- Previous by thread: PROBLEM: Caught SIGFPE exceptions aren't reset
- Next by thread: Re: PROBLEM: Caught SIGFPE exceptions aren't reset
- Index(es):
Relevant Pages
|
