blob: 02e90a5268ca5c2a71c147ff1e5e91ee814748fd (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
graphic: 0.952
instruction: 0.927
device: 0.774
vnc: 0.732
assembly: 0.717
boot: 0.654
semantic: 0.628
other: 0.581
socket: 0.567
network: 0.461
KVM: 0.314
mistranslation: 0.128
SPARC fp operation INVALID trap hangs on offending instruction.
Description of problem:
An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward.
This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal.
It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail?
`#include <ieeefp.h>`
`main()`
`{`
`double val;`
`int i;`
`fpsetmask(FP_X_INV);`
`val = 1000000000000003.0; /* Number that is too large for int */`
`printf("val is %f\n", val);`
`i = val;`
`printf("i is %d\n", i);`
`}`
Steps to reproduce:
1. Enable IEEE iNValid operation traps in the TEM in the FSR.
2. Generate an instruction that causes an iNValid trap
3. Instruction hangs, no SIGFPE is generated
|