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

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

On Sun, 2004-01-25 at 13:27, Dirk Mueller wrote:
> On Sunday 25 January 2004 18:46, Julian Seward wrote:
> 
> > I think a case can be made for both points of view.  However, it
> > seems to me that Jeremy's approach is reasonable enough -- in fact
> > I quite like the sound of it.
> 
> I complain less about the Vendorname change (though I find it pretty 
> pointless, it just introduces an emulation breakage without any good reason 
> for it as far as I can see), but about the "we only tell the user about those 
> flags we know about". There are so many cpu's out there, and so far the only 
> problem we had was that we don't support 3dnow!. I think it is wrong trying 
> to artificially limit the "features" we advertise from those of the host we 
> run on. Tom already found two features that were disabled with this patch 
> which we support just fine - there might be more. 

Those are just typos.  The real issue is that should we claim to support
instruction set features which we don't actually support.  If we claim
to support SSE3 just because the underlying CPU supports it, how does
that help anyone?

All the other feature flags are things which just don't matter to
user-mode programs.  They don't represent any kind of instruction set
extension; they're related to other things like page-table format, power
management, etc.  We could pass them through, but there's no strong
reason to do so.

> Personally, I find it rather frustrating during debugging that whatever I'm 
> trying to look at is "healed" by running under valgrind. This is just another 
> change that purposefully breaks the emulation for (apparently) no good 
> reason. There are a few that are nasty, and are remaining: like syscalls 
> being terrible fast compared to the "normal" case, and the resulting "timing" 
> based races.

Hm?  What's this?

> I haven't tested yet. But to ask another question: which problems does this 
> change fix? Be specific, please. 
> 
> Just give me one concrete bug that can't be fixed without that patch, and I'll 
> shut up.  

The specific thing I wanted to address here was not reporting CPU
capabilities which Valgrind doesn't implement.  Since there's a new wave
of CPUs being released with new feature bits (most importantly Intel's
Prescott, but also AMD's Athlon64), we're going to see new feature flags
appearing, and they need to be handled correctly.

The ValgrindVCPU thing was more a spur of the moment thing, and I'll
think I'll back it out, since it obscures real information.

	J