Issue #6603: Fix --with-tsc build failures on x86-64 that resulted

from a gcc inline assembler peculiarity. (gcc's "A" constraint
apparently means 'rax or rdx' in 64-bit mode, not edx:eax
or rdx:rax as one might expect.)

1 files changed, 19 insertions, 1 deletions

diff --git a/Python/ceval.c b/Python/ceval.c
index ea4bd053c6..dd820f2985 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -51,11 +51,29 @@ ppc_getcounter(uint64 *v)
 	((long*)(v))[1] = tb;
 }
 
-#else /* this is for linux/x86 (and probably any other GCC/x86 combo) */
+#elif defined(__i386__)
+
+/* this is for linux/x86 (and probably any other GCC/x86 combo) */
 
 #define READ_TIMESTAMP(val) \
      __asm__ __volatile__("rdtsc" : "=A" (val))
 
+#elif defined(__x86_64__)
+
+/* for gcc/x86_64, the "A" constraint in DI mode means *either* rax *or* rdx;
+   not edx:eax as it does for i386.  Since rdtsc puts its result in edx:eax
+   even in 64-bit mode, we need to use "a" and "d" for the lower and upper
+   32-bit pieces of the result. */
+
+#define READ_TIMESTAMP(val) \
+    __asm__ __volatile__("rdtsc" : \
+                         "=a" (((int*)&(val))[0]), "=d" (((int*)&(val))[1]));
+
+
+#else
+
+#error "Don't know how to implement timestamp counter for this architecture"
+
 #endif
 
 void dump_tsc(int opcode, int ticked, uint64 inst0, uint64 inst1,