Bug 419271

Summary: false positives due to not recognizing vpxor as dependency breaking idiom
Product: [Developer tools] valgrind Reporter: Radoslaw Zarzynski <rzarzyns>
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED UNMAINTAINED    
Severity: normal    
Priority: NOR    
Version First Reported In: 3.13.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Radoslaw Zarzynski 2020-03-26 14:59:43 UTC
Following code is a variant of dependency breaking idiom:

    vmovdqa %xmm0,%xmm3
    vpxor   %xmm0,%xmm3,%xmm3

Value of xmm3 will always be cleared but it seems Valgrind misses that
when computing the validity bits:

    (gdb) info registers xmm3 xmm3s1 xmm3s2
    xmm3           {... uint128 = 0x00000000000000000000000000000000}
    xmm3s1         {... uint128 = 0xffffffffffffff000000000000000000}

More output from gdb on debugging `gcm_ghash_avx` of OpenSSL: 

    Breakpoint 2, gcm_ghash_avx () at ghash-x86_64.s:1365
    1365            vzeroupper
    (gdb) stepi
    ...
    1598            vmovdqa %xmm0,%xmm3
    (gdb) info registers xmm0 xmm0s1 xmm0s2
    xmm0           {... uint128 = 0x0000000000b4560115ffdd21dcc25ea8}
    xmm0s1         {... uint128 = 0xffffffffffffff000000000000000000}
    xmm0s2         {... uint128 = 0x00000000000000000000000000000000}
    (gdb) stepi
    1599            vmovdqa %xmm1,%xmm4
    (gdb) info registers xmm3 xmm3s1 xmm3s2
    xmm3           {... uint128 = 0x0000000000b4560115ffdd21dcc25ea8}
    xmm3s1         {... uint128 = 0xffffffffffffff000000000000000000}
    xmm3s2         {... uint128 = 0x00000000000000000000000000000000}
    (gdb) stepi
    1600            vmovdqa %xmm2,%xmm5
    (gdb) stepi
    1601            subq    $0x10,%rcx
    (gdb)
    1602            jz      .Ltail_avx
    (gdb)
    1696            vpxor   %xmm10,%xmm15,%xmm15
    (gdb)
    1698            vpunpckhqdq     %xmm15,%xmm15,%xmm8
    (gdb)
    1699            vpxor   %xmm0,%xmm3,%xmm3
    (gdb) stepi
    1700            vpclmulqdq      $0x00,%xmm6,%xmm15,%xmm0
    (gdb) info registers xmm0 xmm0s1 xmm0s2
    xmm0           {... uint128 = 0x0000000000b4560115ffdd21dcc25ea8}
    xmm0s1         {... uint128 = 0xffffffffffffff000000000000000000}
    xmm0s2         {... uint128 = 0x00000000000000000000000000000000}
    (gdb) info registers xmm3 xmm3s1 xmm3s2
    xmm3           {... uint128 = 0x00000000000000000000000000000000}
    xmm3s1         {... uint128 = 0xffffffffffffff000000000000000000}
    xmm3s2         {... uint128 = 0x00000000000000000000000000000000}
Comment 1 Julian Seward 2020-04-17 13:27:18 UTC
I'm pretty sure this is fixed in 3.15.0 or in the trunk.  Closing.
If it still happens in the trunk, please reopen.