|
From: Padala D. <pad...@gm...> - 2018-10-24 11:20:27
|
Hi 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 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: Thanks & Regards Dileep Padala |
|
From: John R. <jr...@bi...> - 2018-10-24 13:54:44
|
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: |
|
From: John R. <jr...@bi...> - 2018-10-24 15:34:45
|
On 10/24/18, Padala Dileep wrote: > I see below information > which /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++ > x86_64-montavista-linux-gnu-g++ (MontaVista Linux G++ 4.7-140716013314) 4.7.0 > > /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++ --print-file-name=libc.so > /opt/mv_7/install/x86_64/montavista/tools/x86_64-gnu/libexec/../x86_64-montavista-linux-gnu/sys-root/usr/lib/../lib64/libc.so > On Wed, Oct 24, 2018 at 8:00 PM Padala Dileep <pad...@gm... <mailto:pad...@gm...>> wrote: > > Hi John, > Thanks for your response. > Which libc (glibc, uClibc, dietLibc, musl, ...) does this system have? > How to check this one? > Did you do anything to libc after installation, such as strip symbols? No > (Or did the install process itself strip symbols?) No > > The libraries generally gets store in a directory /lib on the target, I have treid setting the VALGRIND_PATH to this library path Complain to MontaVista: they are unfriendly to valgrind, which means unfriendly to software developers who use MontaVista products. They have compiled ld-linux.so.2 such that 'strlen' has been inlined using SSE* instructions. That cannot possibly make any difference in the speed of ld-linux, but it is obnoxious to valgrind. MontaVista should compile ld-linux with -fno-builtin-strlen . Meanwhile you should use a software development environment that is friendly to valgrind. For esoteric technical details see: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1247026/comments/12 |
|
From: Padala D. <pad...@gm...> - 2018-10-24 15:45:14
|
Hi John, Thanks for clarifying the issue with monta-vista. So i cannot proceed to use vlagrind on my target. I have two targets. root@Infinera-Linux lib]# uname -a Linux xx-Linux 3.10.40.cge-rt38 #2 SMP Thu Nov 6 13:58:21 PST 2014 i686 GNU/Linux for which export CC=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-gcc is used root@arm_hw:~# uname -a Linux arm_hw 3.10.53.cge-rt50 #1 PREEMPT Tue Aug 1 14:39:13 IST 2017 armv7l GNU/Linux for which export CC=/opt/mv_7/arm/tools/arm-gnu/bin/arm-montavista-linux-gnueabi-gcc is used . These are the two environments my product runs. I am not sure if I can use any other software development evirionment Thanks & Regards Dileep On Wed, Oct 24, 2018 at 9:06 PM John Reiser <jr...@bi...> wrote: > On 10/24/18, Padala Dileep wrote: > > I see below information > > > which /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++ > > x86_64-montavista-linux-gnu-g++ (MontaVista Linux G++ 4.7-140716013314) > 4.7.0 > > > > /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++ > --print-file-name=libc.so > > > /opt/mv_7/install/x86_64/montavista/tools/x86_64-gnu/libexec/../x86_64-montavista-linux-gnu/sys-root/usr/lib/../lib64/libc.so > > > On Wed, Oct 24, 2018 at 8:00 PM Padala Dileep <pad...@gm... > <mailto:pad...@gm...>> wrote: > > > > Hi John, > > Thanks for your response. > > Which libc (glibc, uClibc, dietLibc, musl, ...) does this system > have? > > How to check this one? > > Did you do anything to libc after installation, such as strip > symbols? No > > (Or did the install process itself strip symbols?) No > > > > The libraries generally gets store in a directory /lib on the > target, I have treid setting the VALGRIND_PATH to this library path > > Complain to MontaVista: they are unfriendly to valgrind, which means > unfriendly > to software developers who use MontaVista products. They have compiled > ld-linux.so.2 > such that 'strlen' has been inlined using SSE* instructions. That cannot > possibly > make any difference in the speed of ld-linux, but it is obnoxious to > valgrind. > MontaVista should compile ld-linux with -fno-builtin-strlen . > Meanwhile you should use a software development environment that is > friendly to valgrind. > > For esoteric technical details see: > https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1247026/comments/12 > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |