9

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).

1

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

2
  • Interesting ... – Pierre.Vriens May 10 '17 at 9:24
  • 1
    That didn't work for me. I still get "???" instead of actual debug symbols. – Geremia Sep 19 '18 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.