From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kxmz6-0001Zt-2Y for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:20:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kxmz3-0001VP-K2 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:20:03 -0500 Received: from [199.232.76.173] (port=55591 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kxmz3-0001V6-FG for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:20:01 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:23192) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kxmz2-0007q5-NK for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:20:01 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id mA5IJvoh005410 for ; Wed, 5 Nov 2008 19:19:57 +0100 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail1.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id mA5IJsu8016056 for ; Wed, 5 Nov 2008 19:19:57 +0100 Message-ID: <4911E3CB.1040109@siemens.com> Date: Wed, 05 Nov 2008 19:19:55 +0100 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] x86: FP binary format and overlapping with MMX Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, while refactoring and enhancing the x86 part of gdbstub, I came across an issue in the way CPUX86State.fpregs is stored: According to Intel specs, floating point register bits 0..63 map on MMX register bits 0..63. But this union union { #ifdef USE_X86LDOUBLE CPU86_LDouble d __attribute__((aligned(16))); #else CPU86_LDouble d; #endif MMXReg mmx; } fpregs[8]; only ensures this if a) the host is little endian (due to sizeof(d) > sizeof(mmx)) and b) CPU86_LDouble is actually laid out as on real x86. How a) can be violated is obvious, but what about b)? It seems that qemu is using different binary representations, depending on the FPU emulation mode (native vs. soft). On x86 emulating x86, this is no issue, as the double extended float type (80 bits) is natively available and used. But when going to other host archs, possibly defining CPU86_LDouble as float128, correctness is lost, specifically /wrt saving/restoring the cruft to/from memory where the guest can fiddle with individual bits. Moreover, that's where I came from, byte-swapping for gdb becomes impossible: should I swap MMX or should I convert/swap FP representation? Thoughts on this welcome! Jan -- Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux