Bug 22954 - Conditional jump or move depends on uninitialised value(s) in at 0x519BD27: __wmemchr_avx2 (memchr-avx2.S:260)
Summary: Conditional jump or move depends on uninitialised value(s) in at 0x519BD27: _...
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-13 08:08 UTC by Martin Liska
Modified: 2018-03-31 12:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liska 2018-03-13 08:08:36 UTC
Hello.

With current thunk I see:

$ valgrind --leak-check=yes --trace-children=yes ~/bin/binutils/bin/ld --eh-frame-hdr -m elf_x86_64
...
==21255== Conditional jump or move depends on uninitialised value(s)
==21255==    at 0x519BD27: __wmemchr_avx2 (memchr-avx2.S:260)
==21255==    by 0x510A579: internal_fnwmatch (fnmatch_loop.c:168)
==21255==    by 0x510D5D7: fnmatch@@GLIBC_2.2.5 (fnmatch.c:433)
==21255==    by 0x447DC8: find_target (targets.c:1590)
==21255==    by 0x447EB8: bfd_set_default_target (targets.c:1624)
==21255==    by 0x40348E: main (ldmain.c:246)
...

When I put there a printf:

diff --git a/bfd/targets.c b/bfd/targets.c
index 43102d428b..7765c9ec53 100644
--- a/bfd/targets.c
+++ b/bfd/targets.c
@@ -1586,6 +1586,7 @@ find_target (const char *name)
      config.sub first, but that is hard.  */
   for (match = &bfd_target_match[0]; match->triplet != NULL; match++)
     {
+      fprintf (stderr, "pattern: %s, name: %s\n", match->triplet, name);
       if (fnmatch (match->triplet, name, 0) == 0)
 	{
 	  while (match->vector == NULL)

I see:
...
pattern: i[3-7]86-*-linux-*, name: x86_64-pc-linux-gnu
pattern: i[3-7]86-*-redox*, name: x86_64-pc-linux-gnu
pattern: x86_64-*-dicos*, name: x86_64-pc-linux-gnu
==21255== Conditional jump or move depends on uninitialised value(s)
==21255==    at 0x519BD27: __wmemchr_avx2 (memchr-avx2.S:260)
==21255==    by 0x510A579: internal_fnwmatch (fnmatch_loop.c:168)
==21255==    by 0x510D5D7: fnmatch@@GLIBC_2.2.5 (fnmatch.c:433)
==21255==    by 0x447DC8: find_target (targets.c:1590)
==21255==    by 0x447EB8: bfd_set_default_target (targets.c:1624)
==21255==    by 0x40348E: main (ldmain.c:246)
==21255== 
pattern: x86_64-*-elf*, name: x86_64-pc-linux-gnu
pattern: x86_64-*-rtems*, name: x86_64-pc-linux-gnu
pattern: x86_64-*-fuchsia, name: x86_64-pc-linux-gnu
pattern: x86_64-*-dragonfly*, name: x86_64-pc-linux-gnu
...

Maybe it's an issue of glibc, maybe valgrind can't handle that properly?
Thanks
Comment 1 H.J. Lu 2018-03-13 11:25:53 UTC
(In reply to Martin Liska from comment #0)
> Maybe it's an issue of glibc, maybe valgrind can't handle that properly?
> Thanks

__wmemchr_avx2 uses vector compare and checks the elements of a vector
within boundary:

L(first_vec_x1_check):
        tzcntl  %eax, %eax
        /* Check the end of data.  */
        cmpq    %rax, %rdx
        jbe     L(zero)
        addq    $VEC_SIZE, %rax
        addq    %rdi, %rax
        VZEROUPPER
        ret