John Reiser writes: > It seems to me that there may be at least one set of cases where > the memcheck complaint might be correct, namely if there is no '\0' > in an allocated block whose length is not a multiple of 16.
If there is no `\0` in your string and you call strlen(), I agree we need to issue an error! But I am not suggesting suppressing errors via any kind of heuristic. I am suggesting improving the machine model in order to reduce false positives. > [Example: blk = malloc(11); allocator delivers block of > 16 bytes; memcpy(blk, "123456789AB", 11); if (x < strlen(blk)) ...;] > Then pcmpeqb examines blk[11] that is beyond the malloc()ed length. > That's a true error unless it can be proved that the uninit > portion of the pcmpeqb result (the 0xF800 bits of the mask) > never is used. Proving that the pmovmskb and the bsf do not > depend on the uninit bits is hard. Perhaps I am missing something, but I do not see why this is hard. Memcheck already tracks validity bits. When partial_loads_ok is true, we just need to mark the bits read from beyond the end of the block as "undefined", because that is what they are. True, valgrind does not currently allow memcheck to propagate those validity bits for pmovmskb, but that is a different bug and fairly simple to fix: The validity bits of the result of pmovmskb inherit the validity of the bits that got moved, just like any time bits get moved. Handling bsf is then trivial, and it might even work already: You do a bsf on the shadow register; compare to the bsf result on the data; and if the former is smaller than the latter you set the result's validity bits to "undefined". (The idea is that if the first-set-bit comes earlier than the first-undefined-bit, the result is defined; else it is not.) This would handle the SSE-optimized strlen() and, I suspect, many many other cases besides. And it would generate an error for the case you describe. (The error would be "use of uninitialized data" rather than "read beyond end of block", but this strikes me as reasonable when you set --partial-loads-ok=yes.) I bet the pcmpXXX + pmovmskb + bsf is a common idiom. The final result is that an error will be issued precisely when something actually depends on the data read from outside the allocated block, and not otherwise. I have already created a patch to implement partial_loads_ok for 16-byte SSE loads, including setting the validity bits correctly. I hope to clean it up and attach it to the bug later today. Thanks! - Pat ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
