Re: cpuid_eax damages registers (2.4.7pre7)

Linus Torvalds (torvalds@transmeta.com)
Wed, 18 Jul 2001 10:21:42 -0700 (PDT)


On Wed, 18 Jul 2001, Julian Anastasov wrote:
>
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Ok. That has been considered a "stable" gcc for a long time.

We should try to find a work-around.

> > - do a "make arch/i386/kernel/setup.s" both ways, and show what
> > squash_the_stupid_serial_number() looks like.
>
> Both with "a" and "0" (zero) gcc shows same output in setup.s
> (using cpuid_eax):

Ok.

Can you try to do the following in the cpuid_xxx() functions:
- remove the dummy reads (ie leave just the one register in the asm that
we're actually interested in)
- add explicit clobbers for the other registers

So, for example, cpuid_eax() would be roughly

unsigned int eax;
asm("cpuid"
:"=a" (eax)
:"0" (level)
:"bx","cx","dx");
return eax;

(and for the others, you can't really clobber "ax" because it's an input,
so you'd have to leave that as just a "=a" (eax) and hope that gcc gets
that output right.

> lock ; btrl $18,12(%ebx)
> #NO_APP
> xorl %eax,%eax
> #APP
> cpuid <<<-- cpuid_eax
> #NO_APP
> movl %eax,8(%ebx) <<<-- oops

Yes, the above is very definitely a bug in gcc. Oh, well..

> Even by using cpuid(...) replacement the registers are not
> preserved but instead of ebx, the arg "c" is in ebp and the oops does not
> occur:

They don't have ot be preserved per se - gcc just knows that they are
modified, and because gcc doesn't care about the value it just won't use
it.

> After fixing this with cpuid() I can work perfectly with this
> kernel on network activity (45K packets/sec), SMP. So, only cpuid_xxx are
> suspected for now.

The current asms for cpuid_xxx() are correct. The fact that gcc generates
bad code for this case implies that it might happen somewhere else too,
but as egcs-2.91.66 is fairly well tested it may indeed be that this is
the only case where that actually happens.

> I don't preserve the oopses but I can do it if ..

No, your generated assembly is clear enough evidence of what is going on.
Thanks. If you could try the clobber approach, that would be good.

Linus

-
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/