Re: [Xen-devel] test_x86_emulator

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.04.14 at 16:24, <dslutz@xxxxxxxxxxx> wrote:
>> What gcc version are you using? And could you perhaps make both
>> binaries (-O1 and -O2) available for inspection?

So it's indeed a compiler version difference, with both us and them not
being fully correct. The patch below should make things work.

Jan

x86: fix instruction emulator test's xgetbv constraints

The "A" constraint, while documented up to gcc 4.5 as "The a and d
registers, as a pair (for instructions that return half the result in
one and half in the other)," never really behaved that (natural) way,
but always meant (and is now also documented so) %eax _or_ %edx (%rax
_or_ %rdx on x86-64) unless the operand was wide enough to require both
(i.e. more than 32 bits on ix86 and more than 64 bits on x86-64).

Interestingly something internal to the compiler changed between 4.4
and 4.5 to actually expose the difference - up to gcc 4.4 I was unable
to construct a case where, when only the low half of the result is
actually looked at, the result would be considered to be in %edx/%rdx
(and %eax/%rax would be treated as unmodified by the instruction).

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -102,11 +102,11 @@ static int cpuid(
 
 static inline uint64_t xgetbv(uint32_t xcr)
 {
-    uint64_t res;
+    uint32_t lo, hi;
 
-    asm ( ".byte 0x0f, 0x01, 0xd0" : "=A" (res) : "c" (xcr) );
+    asm ( ".byte 0x0f, 0x01, 0xd0" : "=a" (lo), "=d" (hi) : "c" (xcr) );
 
-    return res;
+    return ((uint64_t)hi << 32) | lo;
 }
 
 #define cpu_has_avx ({ \

Attachment: x86-emul-test-xgetbv-constraint.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel