Re: [Valgrind-users] Runtime error while running valgrind binary

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

On 10/24/18, Padala Dileep wrote:
> I have cross compiled the  valgrind binary and trying to run on my target machine.I am getting the below error.
> my target machine:
> uname -a   --  Linux  xxxxxxx  Thu Nov 6 13:58:21 PST 2014 i686 GNU/Linux
> 
> On My build mechine I gave the configure option like below  as the same  compiler we use for the other binaries for the same target
> export CXX=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
> export CC=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-gcc
> ./configure  --host=-x86_64-montavista-linux --target=x8_64-montavista-linux  --prefix=/home/xxxxx/valgrind
> i also tried giving target as target-i686. But valgrind executable thrown error " cannot execute binary"
> 
> 
> ~]# ./valgrind ./binaryname
> ==1899== Memcheck, a memory error detector
> ==1899== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==1899== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==1899== Command: ./Frm20xd
> ==1899==
> 
> valgrind:  Fatal error at startup: a function redirection
> valgrind:  which is mandatory for this platform-tool combination
> valgrind:  cannot be set up.  Details of the redirection are:
> valgrind:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      strlen
> valgrind:  in an object with soname matching:   ld-linux.so.2
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux.so.2

Which libc (glibc, uClibc, dietLibc, musl, ...) does this system have?
Did you do anything to libc after installation, such as strip symbols?
(Or did the install process itself strip symbols?)

Valgrind's message is crystal clear: ld-linux.so.2 does not export 'strlen',
which is required for sane operation of valgrind (actually, to prevent
"false positive" complaints from memcheck about typical code in strlen
that is too hard to recognize and analyze quickly.)
Also, run "readelf --segments ./Frm20xd" and check the [PT_]INTERP
for the exact path to ld-linux.so.2.

You should do what valgrind's message says: install the debug symbols
for your libc.  If you cannot do that, then you cannot run memcheck.

> valgrind:
> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
> valgrind:  package on this machine.  (2, longer term): ask the packagers
> valgrind:  for your Linux distribution to please in future ship a non-
> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind:  that exports the above-named function using the standard
> valgrind:  calling conventions for this platform.  The package you need
> valgrind:  to install for fix (1) is called
> valgrind:
> valgrind:    On Debian, Ubuntu:                 libc6-dbg
> valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
> valgrind:
> valgrind:  Note that if you are debugging a 32 bit process on a
> valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
> valgrind:  package (e.g. libc6-dbg:i386).
> valgrind: