Re: [Valgrind-users] mandatory function redirection error

[John R. <jr...@bi...>]

[[Inconsistently quoted, for brevity.]]

> The actual source of memcheck's complaint is coregrind/m_redir.c:
> void VG_(redir_initialise) ( void )
>    <<snip>>
> #  elif defined(VGP_arm_linux)
>    /* If we're using memcheck, use these intercepts right from
>       the start, otherwise ld.so makes a lot of noise. */
>    if (0==VG_(strcmp)("Memcheck", VG_(details).name)) {
>       add_hardwired_spec(
>          "ld-linux.so.3", "strlen",
>          (Addr)&VG_(arm_linux_REDIR_FOR_strlen),
>          complain_about_stripped_glibc_ldso
>       );
>       //add_hardwired_spec(
>       //   "ld-linux.so.3", "index",
>       //   (Addr)&VG_(arm_linux_REDIR_FOR_index),
>       //   NULL
>       //);
>       add_hardwired_spec(
>          "ld-linux.so.3", "memcpy",
>          (Addr)&VG_(arm_linux_REDIR_FOR_memcpy),
>          complain_about_stripped_glibc_ldso
>       );
>    }


> I finally got around to trying this.  I used 'trunk' in the svn command,
> which I hope is what you meant by top-of-trunk.  It had both the strlen
> and memcpy sections that you mention above uncommented, so I tried
> commending out the memcpy secion.  I then got an error just like the one
> I originally described, except it referred to strlen.  So I tried again
> with that section commented out as well.  Then the program ran, but I
> got some scary messages:
>
> root@bboneumh2:~/software# ~/local/bin/valgrind --leak-check=yes
> ./clock_gettime CLOCK_MONOTONIC
> ==28151== Memcheck, a memory error detector
> ==28151== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==28151== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
> ==28151== Command: ./clock_gettime CLOCK_MONOTONIC
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151==    at 0x400B308: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151==    at 0x400B344: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151==    at 0x400C0C8: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151==    at 0x400B1C0: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151==    at 0x400B1C8: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> 234081.669967
> ==28151==
> ==28151== HEAP SUMMARY:
> ==28151==     in use at exit: 0 bytes in 0 blocks
> ==28151==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==28151==
> ==28151== All heap blocks were freed -- no leaks are possible
> ==28151==
> ==28151== For counts of detected and suppressed errors, rerun with: -v
> ==28151== Use --track-origins=yes to see where uninitialised values come from
> ==28151== ERROR SUMMARY: 17 errors from 5 contexts (suppressed: 0 from 0)
> 
> I haven't seen anything like those messages before.  Are they likely
> related to the commented-out sections?

Very probably these are due to calls on strlen() or memcpy()
which have been expanded inline because of aggressive optimization
("#include <string.h>" compiled with -O2 or -O3.)
You can check this by examining the generated assembly code
which surrounds the addresses mentioned (0x400B308, 0x400B344, 0x400C0C8, etc.,
which are runtime addresses that are 0x4000000 higher than the addresses
in the filesystem copy of ld-2.12.2.so [or 0x0 higher in case ld-linux
has been prelinked.])  It should look like strlen or memcpy.

Assuming that it does look like strlen or memcpy, then it is safe to construct
and use one or more suppression rules in order to hide these complaints
in the future.  (We know [assume] that it is safe because other platforms
have hit this problem before, and the code is "the same".  In any event,
you as a "mere" user of ld-linux cannot do anything about that code, so don't
listen to those complaints.)  Invoke valgrind using the additional argument
"--gen-suppressions=yes" and see the documentation about adding the output
to the default suppressions for your platform.

The other choice is to ask the supplier of your glibc for a version of ld-linux
that is compiled without -O2 and without -O3.  [ld-linux is a part of glibc]
Your supplier of ld-linux is acting unfriendly to developers by not making
such a version readily available.  This problem has been known generally
for several years by embedded developers on many platforms.  You should
raise your voice and complain somewhat forcefully to your supplier of ld-linux.
[Of course, this being open source, in theory you could re-compile ld-linux
yourself.  But it is somewhat difficult, cumbersome, and long.]

--