All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Sharma <arun.sharma@intel.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: [PATCH] libxc-x86-64-fixes.patch
Date: Tue, 29 Mar 2005 22:26:11 -0800	[thread overview]
Message-ID: <424A4683.9040803@intel.com> (raw)
In-Reply-To: <424A1FAE.6000106@us.ibm.com>

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

      reply	other threads:[~2005-03-30  6:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-29 23:33 [PATCH] libxc-x86-64-fixes.patch Arun Sharma
2005-03-30  3:40 ` Anthony Liguori
2005-03-30  6:26   ` Arun Sharma [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=424A4683.9040803@intel.com \
    --to=arun.sharma@intel.com \
    --cc=Ian.Pratt@cl.cam.ac.uk \
    --cc=aliguori@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.