From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37769 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PEmNL-0002v0-LZ for qemu-devel@nongnu.org; Sat, 06 Nov 2010 13:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PEmNK-0002Ca-GM for qemu-devel@nongnu.org; Sat, 06 Nov 2010 13:16:23 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:52332 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PEmNK-0002Bo-9m for qemu-devel@nongnu.org; Sat, 06 Nov 2010 13:16:22 -0400 Date: Sat, 6 Nov 2010 20:16:13 +0300 (MSK) From: malc Subject: Re: [Qemu-devel] Bug report about x86 'bt' insn In-Reply-To: <86eiay344b.fsf@shell.gmplib.org> Message-ID: References: <86eiay344b.fsf@shell.gmplib.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Torbjorn Granlund Cc: qemu-devel@nongnu.org On Sat, 6 Nov 2010, Torbjorn Granlund wrote: > [This is a bug report, reported here since I was redirected to some > corporate site when attempting to follow the recommended bug report > practice. If I am really required to register an account with a > corporation in order to report a qemu bug, and that bug reports are not > accepted here, then please accept my apology; I suggest that you simply > ignore this bug report.] > > Bug report: > > Qemu version: 0.13.0 (installed via FreeBSD's ports system). > > Host: FreeBSD 8.1 amd64 (without any relevant kernel modules) > > Guest environments where problem has been reproduced: (1) Debian GNU/Linux > 5, (2) Debian GNU/kFreeBSD snapshot, (3) FreeBSD 8.1 > > Problem: The bt insn works incorrectly under qemu. It incorrectly sets > the Z flag. The bt insn should only affect the carry flag. (This > causes the GMP library to work incorrectly.) > > Test code snippet: > > .text > .globl main > main: mov $1, %eax > and %eax, %eax > bt $0, %eax > jz 1f > xor %eax, %eax > 1: ret > > Assembly and execute. Correct behaviour is to exit(0). Under qemu it > it exits with value 1. ZF is undefined according to AMD's 24594.pdf page 69. > > (I thought qemu wouldn't interfere with plain user mode instructions > when the host system can handle all the guest systems's instructions, > and that they would execute natively and at full speed. This bug > suggests that buggy emulation is taking place.) > > -- mailto:av1474@comtv.ru