Joel Sherrill wrote:
I hacked on that test program to get the attached
program. I ran it multiple times on qemu.
ext=0x0 sig=0x756e6547
0x781abfd YES on SSE2
I am now printing the return value from __get_cpuid_max()
ext=0x0 sig=0x756e6547 returned=0x2
0x781abfd YES on SSE2
Isn't the "sig" supposed to be >= 0x80000000?
No, it says "uneG" in Intel speak, as in "_Genu_ine Intel"
I ran the same program natively and got this:
ext=0x0 sig=0x756e6547
0xbfebfbff YES on SSE2
I wonder if qemu is just reporting things wrong. :(
I searched the qemu manual and googled some but
didn't see anything that jumped out.
Does this look like qemu reporting a bogus cpuid or
gcc not parsing it correctly?
This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in
http://download.intel.com/design/processor/applnots/24161832.pdf,
section 2: "Detecting the CPUID Instruction".
I added a print before the return on !__get_cpuid and it is returning
non zero.
So, this is qemu bug. It advertises CPUID support with %eax=2, and when
queried with cpuid, it returns SSE2 support. Either SSE2 should be fully
fixed in quemu, or it should stop advertising SSE2 (and other levels)
support.
It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...
The call to __get_cpuid is checking against level 1 and this is a level 2.
This is cpuid level, not SSE level. We want cpuid information indexed
with %eax=1.
Uros.
