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:
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
