|
From: Jeremy F. <je...@go...> - 2003-11-19 23:11:40
|
On Wed, 2003-11-19 at 14:53, Jonathan Payne wrote: > Thanks for implementing the MMX instruction set! > > Now that we can run with mmx enabled we're seeing the "uninitialized > value" warning quite a bit. As far as we can tell everything works just > fine so this feels like a false positive. I've stepped into the > debugger when the errors occur and all the addresses look fine as well - > the pointers are well within the middle of a large array that has been > written to many times before the error starts showing up. > > Has anybody else seen this? Normally memcheck will ignore it if you merely read an undefined value - it's only when you use it as a pointer or in a conditional does it complain. But for floating point instructions (which includes MMX), it checks for validity when you do the read, regardless of what you do with the data later on. Your program shows why memcheck spends so much effort in tracking undefined values around rather than complaining as soon as they appear. Perfectly ordinary, correct programs can result in undefined values appearing. For example, a structure may have holes left by padding, which are never initialized. If you do memcpy(&a, &b, sizeof(a)), then this will copy the undefined holes into a from b. With your memcpy_mmx, this will raise spurious errors, because it will read the holes along with everything else and complain about them. There's no easy fix, unfortunately. memcheck doesn't do a detailed model of the FPU or MMX instructions like it does with integer instructions, so it can't do bit-by-bit tracking. Until Valgrind is taught a more complete model, there's no real workaround, other than to initialize everything. J |