Re: [Valgrind-users] false positive?!?

[<Woe...@on...>]

On Friday 20 October 2006 02:38, Julian Seward wrote:
> > mov    0x40(%rbp),%eax
> > or     $0x1,%eax
> > inc    %ax
> > je     0x504ba10 <_ZN16QXmlSimpleReader11parsePrologEv+1120>
> >
> > I don't know why an ushort is loaded to eax
>
> Either it's a harmless gcc oddity, or it's to observe some kind of
> store-to-load-forwarding optimisation guideline for your CPU.
> But that's not important right now.
>
> > but as only ax is
> > incremented why does this trigger a warning in valgrind?
>
> Because memcheck incorrectly believes (from the point of view of the
> definedness tracking) that the 'je' depends on the carry flag
> (%rflags.c).  However that is not changed by the 'inc' but it is
> set by the 'or', which since that used a half-garbage value from
> the stack, sets it to 'undefined'.

My assembler knowledge is a bit rusty, 'or' changes the carry flag?

> Never mind.  Try this: in VEX/priv/guest-amd64/ghelper.c function
> guest_amd64_spechelper find the case for DECW (will be obvious,
> near line 1188) and after it add this:
>
>       /*---------------- INCW ----------------*/
>
>       if (isU64(cc_op, AMD64G_CC_OP_INCW) && isU64(cond, AMD64CondZ))
> { /* 16-bit inc, then Z --> test dst =3D=3D 0 */
>          return unop(Iop_1Uto64,
>                      binop(Iop_CmpEQ64,
>                            binop(Iop_Shl64,cc_dep1,mkU8(48)),
>                            mkU64(0)));
>       }
>
> Rebuild (make clean ; make ; make install) and try again.  Does
> that fix it?

I tried it with 3.2.1 and it works :-) Thanks!


Cheers,
Andr=E9