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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
debug: 0.936
ppc: 0.933
user-level: 0.932
performance: 0.927
architecture: 0.927
vnc: 0.925
register: 0.924
hypervisor: 0.924
socket: 0.923
permissions: 0.923
risc-v: 0.923
virtual: 0.921
mistranslation: 0.921
semantic: 0.918
graphic: 0.916
peripherals: 0.914
PID: 0.908
KVM: 0.908
device: 0.903
assembly: 0.899
x86: 0.894
arm: 0.893
VMM: 0.889
boot: 0.884
kernel: 0.883
files: 0.878
TCG: 0.874
network: 0.865
i386: 0.851
mips/mipsel linux user float division problem
Hi,
I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program:
#include <stdio.h>
int main(int argc, char **argv)
{
int a = 1;
double d = a/2.0;
printf("%f\n", d);
return 0;
}
Instead of printing 0.5, it will print 2.0 if executed in qemu user mode.
$ mipsel-linux-gnu-gcc mipstest.c
$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out
2.0
Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode.
Can anybody else reproduce this problem?
I can confirm that something is strange with MIPS Linux user emulation, but get a different result (which is also wrong):
# Your test code is in file divtest.c.
$ mipsel-linux-gnu-gcc-4.7 -g -static divtest.c
$ mipsel-linux-user/qemu-mipsel a.out
0.000000
Some more tests:
printf("%f\n", a * 1.0); // 0.000000 = bad
printf("%f\n", (double)a); // 0.000000 = bad
printf("%f\n", 1.0); // 1.000000 = good
Test environment:
* latest QEMU sources + default configure & make on x86_64 Debian squeeze host
* gcc-4.7-mipsel-linux-gnu 4.7.2-5 amd64 GNU C compiler
Here is the related commit found by git bisect:
$ git bisect bad
68473f15d4c9948986618f63828825beafcaf1cf is the first bad commit
commit 68473f15d4c9948986618f63828825beafcaf1cf
Author: Richard Henderson <email address hidden>
Date: Sun Feb 10 10:30:46 2013 -0800
mips64-linux-user: Enable 64-bit address mode and fpu
Signed-off-by: Richard Henderson <email address hidden>
Signed-off-by: Aurelien Jarno <email address hidden>
:040000 040000 de3caa25e43aaeb7d992715b2efc6804a7d0d633 b007b2a9809547197952ca4d36fbd29f89aab470 M target-mips
On 2 October 2013 02:51, Stefan Weil <email address hidden> wrote:
> I can confirm that something is strange with MIPS Linux user emulation,
> but get a different result (which is also wrong):
>
> # Your test code is in file divtest.c.
> $ mipsel-linux-gnu-gcc-4.7 -g -static divtest.c
> $ mipsel-linux-user/qemu-mipsel a.out
> 0.000000
Does the CPU you're asking qemu to emulate match the CPU gcc is
generating code for? IIRC for MIPS there's no single "right" answer
for "which CPU do we default to"...
-- PMM
On 2 October 2013 14:22, Stefan Weil <email address hidden> wrote:
> The original bug report said that it runs in QEMU system emulation
> (which I did not test because of lack of time). As system emulation
> uses the same cpu, it should be fine.
...that's what prompted me to ask, actually -- system emulation will
pick a CPU based on whichever board you're emulating, which is
quite likely to be a different one from the default picked by linux-user.
The original bug report doesn't seem to say which board they used
for system emulation so I don't know which CPU it would be using.
-- PMM
For system emulation I used the default which is malta.
cheers, josch
This is a known issue.
There was a fix proposal by Thomas Schwinge back in June
http://patchwork.ozlabs.org/patch/250161/
but he has not updated the patch per suggestion ever since, though the patch
as is was much closer to correct behaviour than what it is now in the source.
If anyone is in hurry, he/she can pick up that change.
Looks like Petar's patch from comment #6 has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d66261f71f2efa31e1052e
==> Fix released
|