From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: test_x86_emulator Date: Wed, 16 Apr 2014 09:26:44 +0100 Message-ID: <534E5AE40200007800009550@nat28.tlf.novell.com> References: <1396967094-29484-1-git-send-email-dslutz@verizon.com> <1396967094-29484-2-git-send-email-dslutz@verizon.com> <53458CB40200007800007598@nat28.tlf.novell.com> <534592D7.2020805@terremark.com> <534652300200007800007727@nat28.tlf.novell.com> <53475944.3060100@terremark.com> <5347B9BD0200007800007DDB@nat28.tlf.novell.com> <5347D8C4.8080500@terremark.com> <5347F7A10200007800007F74@nat28.tlf.novell.com> <5347E4B1.3080505@terremark.com> <534822E202000078000080AC@nat28.tlf.novell.com> <5348292B.5000102@terremark.com> <534BAD0F0200007800008407@nat28.tlf.novell.com> <534C1AF0.3060707@terremark.com> <534CF2950200007800008C62@nat28.tlf.novell.com> <534D4108.2020100@terremark.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part9FAD8FD4.0__=" Return-path: In-Reply-To: <534D4108.2020100@terremark.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz Cc: Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part9FAD8FD4.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >>> On 15.04.14 at 16:24, 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 --- 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( =20 static inline uint64_t xgetbv(uint32_t xcr) { - uint64_t res; + uint32_t lo, hi; =20 - asm ( ".byte 0x0f, 0x01, 0xd0" : "=3DA" (res) : "c" (xcr) ); + asm ( ".byte 0x0f, 0x01, 0xd0" : "=3Da" (lo), "=3Dd" (hi) : "c" (xcr) = ); =20 - return res; + return ((uint64_t)hi << 32) | lo; } =20 #define cpu_has_avx ({ \ --=__Part9FAD8FD4.0__= Content-Type: text/plain; name="x86-emul-test-xgetbv-constraint.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-emul-test-xgetbv-constraint.patch" x86: fix instruction emulator test's xgetbv constraints=0A=0AThe "A" = constraint, while documented up to gcc 4.5 as "The a and d=0Aregisters, as = a pair (for instructions that return half the result in=0Aone and half in = the other)," never really behaved that (natural) way,=0Abut always meant = (and is now also documented so) %eax _or_ %edx (%rax=0A_or_ %rdx on = x86-64) unless the operand was wide enough to require both=0A(i.e. more = than 32 bits on ix86 and more than 64 bits on x86-64).=0A=0AInterestingly = something internal to the compiler changed between 4.4=0Aand 4.5 to = actually expose the difference - up to gcc 4.4 I was unable=0Ato construct = a case where, when only the low half of the result is=0Aactually looked = at, the result would be considered to be in %edx/%rdx=0A(and %eax/%rax = would be treated as unmodified by the instruction).=0A=0ASigned-off-by: = Jan Beulich =0A=0A--- a/tools/tests/x86_emulator/test_x8= 6_emulator.c=0A+++ b/tools/tests/x86_emulator/test_x86_emulator.c=0A@@ = -102,11 +102,11 @@ static int cpuid(=0A =0A static inline uint64_t = xgetbv(uint32_t xcr)=0A {=0A- uint64_t res;=0A+ uint32_t lo, hi;=0A = =0A- asm ( ".byte 0x0f, 0x01, 0xd0" : "=3DA" (res) : "c" (xcr) );=0A+ = asm ( ".byte 0x0f, 0x01, 0xd0" : "=3Da" (lo), "=3Dd" (hi) : "c" (xcr) = );=0A =0A- return res;=0A+ return ((uint64_t)hi << 32) | lo;=0A }=0A = =0A #define cpu_has_avx ({ \=0A --=__Part9FAD8FD4.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part9FAD8FD4.0__=--