From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40287 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PEjyi-0001kB-HE for qemu-devel@nongnu.org; Sat, 06 Nov 2010 10:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PEjyh-0002Lc-CR for qemu-devel@nongnu.org; Sat, 06 Nov 2010 10:42:48 -0400 Received: from gmplib-02.nada.kth.se ([130.237.222.242]:43089 helo=shell.gmplib.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PEjyh-0002LE-7O for qemu-devel@nongnu.org; Sat, 06 Nov 2010 10:42:47 -0400 From: Torbjorn Granlund Sender: tg@gmplib.org Date: Sat, 06 Nov 2010 15:42:44 +0100 Message-ID: <86eiay344b.fsf@shell.gmplib.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Bug report about x86 'bt' insn List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org [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. (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.) --=20 Torbj=F6rn