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

[Jeremy F. <je...@go...>]

On Sun, 2004-01-25 at 16:57, Dirk Mueller wrote:
> On Monday 26 January 2004 01:16, Jeremy Fitzhardinge wrote:
> 
> > The old code was incorrect, because it just masked out a bit without
> > checking the vendor ID.  That bit is only defined for AMD CPUs.
> 
> Exactly thats why the code was correct. The application that we're 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.  Just clearing the bit means you could
be clearing some other feature flag for another vendor.

> Besides that, the behaviour is defined: those cpus which don't support the 
> extension return 0x00 in all registers. masking out a bit there doesn't hurt 
> at all. 

Yes it does, because other vendors can (and do) have their own
definitions for those operations.

> 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.  If we clear all the unknown
bits, then the program will either behave as it would on an older CPU,
or crash anyway because it uses the new instructions without checking
(as it would on any other CPU which doesn't implement that extension).

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.

> > For the latter, they're only relevent to kernels, and not 
> > user-mode code, since they don't functionally change the CPU's
> > characteristics for user-mode - or if they do, then we don't emulate
> > that change, and so should suppress the bit.
> 
> 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.

> I think its fine for an application to be able to query CPU characteristics, 
> like cache sizes etc even when running under valgrind. 

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

> IMHO as long as the characteristics doesn't affect valgrind emulation in any 
> way: don't hide the information. 

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

> > results.  I'm very uneasy about CPUID returning partially mangled
> > undefined results; we should only return stuff which we *know* to be
> > true, or at worst irrelevant.
> 
> I think it should return all the information the "real" CPU would do too, 
> except for those bits what we *know* to be *false* on our CPU. 

Well, we don't know anything about the reserved bits, since they could
come to mean anything at all in future.  So we have to assume that they
will indicate something we can't handle when they become defined.

> > The old code was fragile and broken, because it always assumed
> > 0x80000001 was returning AMD feature flags.
> 
> Ok, on which CPU does it return something else?

Intel reserve that output, so it could mean anything else.

> Thats why we disabled the 3dnow! capabilities. We didn't disable the SSE ones 
> for that reason because a lot of code uses significantly different codepaths 
> nowadays when the CPU supports SSE. And if those codepaths trigger a bug in 
> your application, you do want to be able to find this bug using valgrind. If 
> running under valgrind makes your application avoid those code paths that 
> trigger the bug, then valgrind is pointless. And we don't want that, do 
> we? :-)

Yes, enough people use SSE that it is worthwhile supporting it. 
Practically nobody uses 3dnow, so nobody made the effort.  For any
future extensions, we'll assume that they're useless until enough people
make a fuss about them to want them implemented.  One program which
happens to use them isn't enough.

	J