|
From: Julian S. <js...@ac...> - 2005-05-03 18:40:53
|
Hi Joern Thanks for the bug report. > This lead me to believe that it is probably the shrd insruction that > looses validity information: Your analysis is right. Up to and including 2.4.0, memcheck approximated the behaviour of shrd/shld (but is exact for the normal shift insns). I can reproduce what you say using 2.4.0. Good news is that the 3.X line uses a new compilation pipeline which is significantly more accurate, not just for sh[lr]d but also for floating point and vector instructions. And so it runs your program without the false warning. 3.0 is still a work in progress, but is fairly solid on x86 and so you may want to use it instead. See http://www.valgrind.org/devel/cvs_svn.html for details on how to check it out of svn and build; it's easy. J (irrelevant details ...) 3.0's translation into IR of the offending insn is ... 0x80484C1: shrdl %cl, %esi, %ebx ------ IMark(0x80484C1, 3) ------ PUT(56) = 0x80484C1:I32 t25 = GET:I32(24) t26 = GET:I32(12) t27 = And8(GET:I8(4),0x1F:I8) t28 = 32HLto64(t25,t26) t29 = 64to32(Shr64(t28,t27)) t30 = 64to32(Shr64(t28,And8(Sub8(t27,0x1:I8),0x1F:I8))) PUT(32) = Mux0X(t27,GET:I32(32),0x1B:I32) PUT(36) = Mux0X(t27,GET:I32(36),t29) PUT(40) = Mux0X(t27,GET:I32(40),t30) PUT(44) = 0x0:I32 PUT(12) = t29 Because memcheck tracks exactly the behaviour of Shr64 and all the other primops, you get exact handling of shrdl "for free". |