[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] x86: FP binary format and overlapping with MMX
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] x86: FP binary format and overlapping with MMX |
Date: |
Wed, 05 Nov 2008 19:19:55 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] x86: FP binary format and overlapping with MMX,
Jan Kiszka <=