Bug 419271 - false positives due to not recognizing vpxor as dependency breaking idiom
Summary: false positives due to not recognizing vpxor as dependency breaking idiom
Status: RESOLVED UNMAINTAINED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: 3.13.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-26 14:59 UTC by Radoslaw Zarzynski
Modified: 2020-04-17 13:27 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.