Re: cpuid_eax damages registers (2.4.7pre7)

Julian Anastasov (ja@ssi.bg)
Thu, 19 Jul 2001 11:23:06 +0300 (EEST)


Hello,

On Wed, 18 Jul 2001, Linus Torvalds wrote:

> Can you verify with this alternate patch instead? Yours works ok on
> older gcc's, but the gcc team feels that clobbers must never cover
> inputs or outputs, so your patch really generates invalid asms. Here's
> a alternate, can you verify that it works for you guys, and perhaps
> people can at the same time eye-ball it for any other issues they can
> think of?

This patch works for me too (I checked all cpuid_XXX calls).
After some thinking I produced another patch. The interesting part is
that __volatile__ solves the problem. Patch appended. I see in other
kernel files that volatile solves gcc bugs. The question is whether
the volatile is needed only as a work-around or it is needed in this
case particulary, i.e. where the output registers are not used and are
optimized.

> Linus

Regards

--
Julian Anastasov <ja@ssi.bg>

--- include/asm-i386/processor.h.orig1 Wed Jul 18 12:03:26 2001 +++ include/asm-i386/processor.h Thu Jul 19 10:58:06 2001 @@ -136,7 +136,7 @@ { unsigned int eax, ebx, ecx, edx;

- __asm__("cpuid" + __asm__ __volatile__ ("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (op)); return eax; @@ -145,7 +145,7 @@ { unsigned int eax, ebx, ecx, edx;

- __asm__("cpuid" + __asm__ __volatile__ ("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (op)); return ebx; @@ -154,7 +154,7 @@ { unsigned int eax, ebx, ecx, edx;

- __asm__("cpuid" + __asm__ __volatile__ ("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (op)); return ecx; @@ -163,7 +163,7 @@ { unsigned int eax, ebx, ecx, edx;

- __asm__("cpuid" + __asm__ __volatile__ ("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (op)); return edx;

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/