Build fixes for x86-64.
Signed-off-by: Nitin Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Arun Sharma <arun.sharma@intel.com>
--- 1.4/tools/libxc/xc_ptrace.c 2005-03-20 07:07:46 -08:00
+++ edited/libxc/xc_ptrace.c 2005-03-29 15:18:27 -08:00
@@ -281,9 +281,9 @@
SET_PT_REGS(pt, ctxt.cpu_ctxt);
memcpy(data, &pt, sizeof(elf_gregset_t));
} else if (request == PTRACE_GETFPREGS)
- memcpy(data, &ctxt.fpu_ctxt, sizeof(elf_fpregset_t));
+ memcpy(data, &ctxt.fpu_ctxt, sizeof(ctxt.fpu_ctxt));
else /*if (request == PTRACE_GETFPXREGS)*/
- memcpy(data, &ctxt.fpu_ctxt, sizeof(elf_fpxregset_t));
+ memcpy(data, &ctxt.fpu_ctxt, sizeof(ctxt.fpu_ctxt));
cr3 = ctxt.pt_base;
regs_valid = 1;
break;
--- 1.14/tools/libxc/xc_vmx_build.c 2005-03-20 03:53:25 -08:00
+++ edited/libxc/xc_vmx_build.c 2005-03-29 15:20:56 -08:00
@@ -478,10 +478,18 @@
{
int eax, ecx;
+#ifdef __i386__
__asm__ __volatile__ ("pushl %%ebx; cpuid; popl %%ebx"
: "=a" (eax), "=c" (ecx)
: "0" (1)
: "dx");
+#elif defined __x86_64__
+ __asm__ __volatile__ ("pushq %%rbx; cpuid; popq %%rbx"
+ : "=a" (eax), "=c" (ecx)
+ : "0" (1)
+ : "dx");
+#endif
+
if (!(ecx & VMX_FEATURE_FLAG)) {
return -1;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Arun Sharma wrote:> >+#ifdef __i386__ > __asm__ __volatile__ ("pushl %%ebx; cpuid; popl %%ebx" > : "=a" (eax), "=c" (ecx) > : "0" (1) > : "dx"); >+#elif defined __x86_64__ >+ __asm__ __volatile__ ("pushq %%rbx; cpuid; popq %%rbx" >+ : "=a" (eax), "=c" (ecx) >+ : "0" (1) >+ : "dx"); >+#endif >+ > >Does this mean the ebx-clobbering bug in gcc 3.4 also exists on x86-64 (except it clobbers rbx instead)? I really hate to see this end up a permanent part of the tree... perhaps we should add a Linux style cpuid() function: static inline void cpuid(int op, int *eax, int *ebx, int *ecx, int *edx) { int ax, bx, cx, dx; #if defined __i386__ || defined __x86_64__ __asm__("cpuid" : "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "0" (op)); #else #error cpuid not defined on current architecture #endif if (eax) *eax = ax; if (ebx) *ebx = bx; if (ecx) *ecx = cx if (edx) *edx = dx; } This should take care of the ebx clobbering bug while also resulting in more shared code. Just a thought. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori wrote:> Arun Sharma wrote: > >> >> +#ifdef __i386__ >> __asm__ __volatile__ ("pushl %%ebx; cpuid; popl %%ebx" >> : "=a" (eax), "=c" (ecx) : "0" (1) >> : "dx"); >> +#elif defined __x86_64__ >> + __asm__ __volatile__ ("pushq %%rbx; cpuid; popq %%rbx" >> + : "=a" (eax), "=c" (ecx) >> + : "0" (1) >> + : "dx"); >> +#endif >> + >> >> > Does this mean the ebx-clobbering bug in gcc 3.4 also exists on x86-64 > (except it clobbers rbx instead)? >There was no bug in pre gcc-3.4 generated code in the original version of vmx_identify(). The problem was with some other test case where the compiler generated code used %ebx within the inline assembly (which would be broken because cpuid clobbers %ebx and compiler didn''t realize that). gcc developers instead of making only those cases illegal, made even cases such as ours which look perfectly legal to me, illegal (because it''s too much work for them to figure out what''s legal and what''s not).> I really hate to see this end up a permanent part of the tree... > perhaps we should add a Linux style cpuid() function: > > static inline void cpuid(int op, int *eax, int *ebx, int *ecx, int *edx) > { > int ax, bx, cx, dx; > > #if defined __i386__ || defined __x86_64__ > __asm__("cpuid" > : "=a" (ax), > "=b" (bx), > "=c" (cx), > "=d" (dx) > : "0" (op));As I pointed out in the earlier thread, the linux code in <asm/processor.h> is also broken when used in userland with -fPIC. I used this particular case (<asm/processor.h>) as an argument with gcc developers on why they shouldn''t be making code that was legal with an earlier version of gcc suddenly illegal. But I couldn''t provide enough use cases to make a strong argument and since an easy (although ugly) workaround was available, I settled for it. -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel