diff options
Diffstat (limited to 'results/classifier/105/other/1233225')
| -rw-r--r-- | results/classifier/105/other/1233225 | 121 |
1 files changed, 121 insertions, 0 deletions
diff --git a/results/classifier/105/other/1233225 b/results/classifier/105/other/1233225 new file mode 100644 index 000000000..f37cf9a75 --- /dev/null +++ b/results/classifier/105/other/1233225 @@ -0,0 +1,121 @@ +other: 0.945 +vnc: 0.925 +socket: 0.923 +mistranslation: 0.921 +semantic: 0.918 +graphic: 0.916 +instruction: 0.915 +KVM: 0.908 +device: 0.903 +assembly: 0.899 +boot: 0.884 +network: 0.865 + +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 + |