Jtdylktuy

I'm attempting to install Valgrind on an embedded Debian-based PowerPC system. I've managed to cross-compile it successfully, but now it's complaining that it can't find debug information. I've put non-stripped copies of the relevant shared objects onto the filesystem and informed Valgrind of this directory, but it's still not working.

Invocation:

root@192.168.0.200:/# /root/valgrind/bin/valgrind --extra-debuginfo-path=/root/valgrind/usr/lib/debug /path/to/my_program -log

==6000== Memcheck, a memory error detector

==6000== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.

==6000== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info

==6000== Command: /path/to/my_program -log

==6000==



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.so.1

valgrind:  was not found whilst processing

valgrind:  symbols from the object with soname: ld.so.1

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:  Cannot continue -- exiting now.  Sorry.

The offending file, ld.so.1, is in /lib, and my non-stripped copies are in a separate directory:

root@192.168.0.200:/# find / -name ld.so.1

/lib/ld.so.1

/root/valgrind/usr/lib/debug/ld.so.1

/root/valgrind/usr/lib/debug/lib/ld.so.1

My non-stripped copies from libc6-dbg_2.7-10ubuntu3_powerpc.deb appear to be compatible:

root@192.168.0.200:/# file /lib/ld.so.1 /root/valgrind/usr/lib/debug/ld.so.1 /root/valgrind/usr/lib/debug/lib/ld.so.1

/lib/ld.so.1:                             symbolic link to `ld-2.7.so'

/root/valgrind/usr/lib/debug/ld.so.1:     symbolic link to `ld-2.7.so'

/root/valgrind/usr/lib/debug/lib/ld.so.1: symbolic link to `ld-2.7.so'

root@192.168.0.200:/# file /lib/ld-2.7.so /root/valgrind/usr/lib/debug/ld-2.7.so /root/valgrind/usr/lib/debug/lib/ld-2.7.so

/lib/ld-2.7.so:                             ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with unknown capability 0x41000000 = 0x11676e75, with unknown capability 0x10000 = 0x90401, stripped

/root/valgrind/usr/lib/debug/ld-2.7.so:     ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, not stripped

/root/valgrind/usr/lib/debug/lib/ld-2.7.so: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped

And if I understand how objdump works, it seems like the "must-be-redirected function" mentioned by Valgrind does indeed have an entry in the debug copy:

root@192.168.0.200:/# objdump -x /lib/ld-2.7.so | grep strlen

root@192.168.0.200:/# objdump -x /root/valgrind/usr/lib/debug/lib/ld-2.7.so | grep strlen

0002f734 l     O .data.rel.ro   00000004 max_capstrlen

00018ff0 l     F .text  000000b8 strlen

And yet the --extra-debuginfo-path argument has no effect. There's a brief mention of this switch in the manual, but this is practically all the information I've been able to find about it. Am I missing something else?

For the record, this machine cannot connect to the Internet, so letting apt / dpkg take care of things is sadly out of the question. /lib and most other system directories are also mounted read-only, so I can't just drop in a non-stripped replacement for ld-2.7.so (not that I would take such a risk).

I had a similar issue, and adding --allow-mismatched-debuginfo=yes parameter to valgrind solved the problem.