Re: [Valgrind-developers] Re: valgrind/coregrind

[Dirk M. <dm...@gm...>]

On Monday 26 January 2004 10:40, Jeremy Fitzhardinge wrote:

> > emulating has to check before calling cpuid(0x80000001) if it is in fact
> > a AMD CPU. If they don't, well, they get undefined behaviour anyway.
> No, because other vendors can use 0x80000001 for other purposes.  Intel
> has this reserved, for example. 

intel cleans all bits. 

> Just clearing the bit means you could 
> be clearing some other feature flag for another vendor.

Yes, as I said, one could check first if its an athlon cpu. However, thats not 
what your patch did.

> > Correct. IMHO, we should only expose those which exist at all on the
> > original host cpu. So basically we have to blacklist a few extensions
> > which we don't support.
> But that makes no sense.  At any point, one of the currently reserved
> bits could come into use, and a piece of software will try to use
> instructions which are associated with that bit - requiring an upgrade
> to Valgrind to make any progress at all.

Its not as if valgrind would be a package that requires more than 5 minutes to 
download, configure, compile and install. 

When you use such a ultra new CPU you're going to get a lot more trouble with 
your kernel, your libc and your other runtime environment anyway. 

> After all, Valgrind's intent is not to emulate your actual host CPU, but
> the common useful subset of ia32 implementation - which your host CPU
> happens to be one of.

Is this true? I wonder why we keep adding new instructions then. we could just 
claim to not support cpuid and only implement 386 instructions, not any of 
the "fancy" stuff newer processors do. 

Look, there were good reasons for implementing SSE: for example because of DRI 
drivers that use SSE without checking for it (NVIDIA being a good example). 
There was no way to suppress SSE support, and it was often requested since 
almost every second computer uses those NVIDIA drivers nowadays. 

> > euhm? when does invoking the cpuid instruction change the CPU behavior?
> > Got an example for that?
> It doesn't, but it does indicate CPU behavioural changes.  The only ones
> which user-mode programs care about are instruction-set extensions.

Oh, how do you know what all possible user-mode programs care about? Is there 
some secret source of CPUID wisdom I don't know about yet?

For the single reason that the old code did not expose any problem in any 
existing application that we know of I ask you to consider changing the code 
back to a blacklisting behavior. If you don't want to fix the cpuid masking 
to be athlon specific,then thats fine, I can do that. 

> Yes, I agree.  But that isn't part of the feature bitmasks.

Really? I wonder why I can read about such processor specific information then 
in the documentation  of cpuid on sandpile.org.

> Instruction set changes do affect the emulation.  All the others are a
> big "don't care".  It's trivial to copy them through.

Great. Then why did you break the "copy through" bit ? Thats the point I'm 
complaining about the whole time !


Dirk