mips/mipsel linux user float division problem

Bug #1233225 reported by Johannes Schauer Marin Rodrigues
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

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?

Revision history for this message
Stefan Weil (ubuntu-weilnetz) 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

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

Changed in qemu:
status: New → Confirmed
Revision history for this message
Stefan Weil (ubuntu-weilnetz) wrote :

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

Revision history for this message
Peter Maydell (pmaydell) wrote : Re: [Qemu-devel] [Bug 1233225] Re: mips/mipsel linux user float division problem

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

Revision history for this message
Peter Maydell (pmaydell) wrote :

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

Revision history for this message
Johannes Schauer Marin Rodrigues (josch-deactivatedaccount) wrote :

For system emulation I used the default which is malta.

cheers, josch

Revision history for this message
Petar Jovanovic (mips32r2) wrote :

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.

Revision history for this message
Thomas Huth (th-huth) wrote :

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

Changed in qemu:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.