I have an absolutely fresh installation of Ubuntu 19.04 and I compiled valgrind 3.15 from sources: ./autogen.sh ./configure --prefix=/opt/valgrind315/ --enable-only64bit [<= these options do not really matter] make sudo make install Each time I run it, I get the following: $ /opt/valgrind315/bin/valgrind -v ls -l ==16904== Memcheck, a memory error detector ==16904== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==16904== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info ==16904== Command: ls -l ==16904== --16904-- Valgrind options: --16904-- -v --16904-- Contents of /proc/version: --16904-- Linux version 5.0.0-13-generic (buildd@lcy01-amd64-020) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 --16904-- --16904-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand --16904-- Page sizes: currently 4096, max supported 4096 --16904-- Valgrind library directory: /opt/valgrind315/lib/valgrind --16904-- Reading syms from /usr/bin/ls --16904-- object doesn't have a symbol table --16904-- Reading syms from /usr/lib/x86_64-linux-gnu/ld-2.29.so --16904-- Considering /usr/lib/x86_64-linux-gnu/ld-2.29.so .. --16904-- .. CRC mismatch (computed c34345a7 wanted 87a50cbd) --16904-- object doesn't have a symbol table 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-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.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: valgrind: Cannot continue -- exiting now. Sorry. I installed successfully debug symbols for ld: $ nm /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.29.so | grep '\bstr' 00000000000206e0 t strchr 000000000001d120 t strcmp 0000000000020da0 t strcspn 000000000001d0d0 t strdup 0000000000020900 t strlen 000000000001e560 t strncmp 0000000000020aa0 t strnlen 000000000001b6a0 t strsep I also tried to run with some extra options following, but I got the same result: --allow-mismatched-debuginfo=yes --read-inline-info=yes --extra-debuginfo-path=[different variants] SOFTWARE/OS VERSIONS Linux: Ubuntu 19.04 Compiler: gcc 8.3.0 ADDITIONAL INFORMATION I need to compile my own version of valgrind (the reason is that our software has a huge .bss section, so default repository version of valgrind can not handle it). Before I compiled and ran it with no problems at all (Ubuntu 16.04), and I'm using exactly the same settings now. Valgrind 3.13 drops endless number of Conditional jump or move depends on uninitialised value(s) in /usr/lib/x86_64-linux-gnu/libc-2.29.so
This is really quite odd: --16904-- Reading syms from /usr/lib/x86_64-linux-gnu/ld-2.29.so --16904-- Considering /usr/lib/x86_64-linux-gnu/ld-2.29.so .. --16904-- .. CRC mismatch (computed c34345a7 wanted 87a50cbd) --16904-- object doesn't have a symbol table It has apparently decided that /usr/lib/x86_64-linux-gnu/ld-2.29.so is it's own debug image, but then the checksum doesn't match. Looking at the code the only way I can see to trigger that is a .gnu_debuglink section in the ELF that contains an absolute path but that would be weird and at least on an 18.04 box there is no .gnu_debuglink in ld.so at all as it uses the new build-id technology. Can you do "readelf -l /usr/lib/x86_64-linux-gnu/ld-2.29.so" and post the output here?
Actually there is a debuglink as well but still it shouldn't be absolute. Can you do these commands and provide output as well please: readelf -S /usr/lib/x86_64-linux-gnu/ld-2.29.so readelf -x .gnu_debuglink /usr/lib/x86_64-linux-gnu/ld-2.29.so
Hello Tom, here they are: $ readelf -l /usr/lib/x86_64-linux-gnu/ld-2.29.so Elf file type is DYN (Shared object file) Entry point 0x1090 There are 9 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000f20 0x0000000000000f20 R 0x1000 LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000 0x0000000000020130 0x0000000000020130 R E 0x1000 LOAD 0x0000000000022000 0x0000000000022000 0x0000000000022000 0x000000000000754c 0x000000000000754c R 0x1000 LOAD 0x00000000000295c0 0x000000000002a5c0 0x000000000002a5c0 0x0000000000001a38 0x0000000000001bd0 RW 0x1000 DYNAMIC 0x0000000000029e70 0x000000000002ae70 0x000000000002ae70 0x0000000000000170 0x0000000000000170 RW 0x8 NOTE 0x0000000000000238 0x0000000000000238 0x0000000000000238 0x0000000000000024 0x0000000000000024 R 0x4 GNU_EH_FRAME 0x0000000000026884 0x0000000000026884 0x0000000000026884 0x00000000000006b4 0x00000000000006b4 R 0x4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 GNU_RELRO 0x00000000000295c0 0x000000000002a5c0 0x000000000002a5c0 0x0000000000000a40 0x0000000000000a40 R 0x1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .rela.dyn .rela.plt 01 .plt .plt.got .text 02 .rodata .stapsdt.base .eh_frame_hdr .eh_frame 03 .data.rel.ro .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.gnu.build-id 06 .eh_frame_hdr 07 08 .data.rel.ro .dynamic .got $ readelf -S /usr/lib/x86_64-linux-gnu/ld-2.29.so There are 26 section headers, starting at offset 0x2b4d8: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 0000000000000238 00000238 0000000000000024 0000000000000000 A 0 0 4 [ 2] .hash HASH 0000000000000260 00000260 00000000000000d4 0000000000000004 A 4 0 8 [ 3] .gnu.hash GNU_HASH 0000000000000338 00000338 00000000000000f8 0000000000000000 A 4 0 8 [ 4] .dynsym DYNSYM 0000000000000430 00000430 0000000000000330 0000000000000018 A 5 1 8 [ 5] .dynstr STRTAB 0000000000000760 00000760 0000000000000224 0000000000000000 A 0 0 1 [ 6] .gnu.version VERSYM 0000000000000984 00000984 0000000000000044 0000000000000002 A 4 0 2 [ 7] .gnu.version_d VERDEF 00000000000009c8 000009c8 00000000000000a4 0000000000000000 A 5 5 8 [ 8] .rela.dyn RELA 0000000000000a70 00000a70 0000000000000408 0000000000000018 A 4 0 8 [ 9] .rela.plt RELA 0000000000000e78 00000e78 00000000000000a8 0000000000000018 AI 4 20 8 [10] .plt PROGBITS 0000000000001000 00001000 0000000000000080 0000000000000010 AX 0 0 16 [11] .plt.got PROGBITS 0000000000001080 00001080 0000000000000008 0000000000000008 AX 0 0 8 [12] .text PROGBITS 0000000000001090 00001090 00000000000200a0 0000000000000000 AX 0 0 16 [13] .rodata PROGBITS 0000000000022000 00022000 0000000000004880 0000000000000000 A 0 0 32 [14] .stapsdt.base PROGBITS 0000000000026880 00026880 0000000000000001 0000000000000000 A 0 0 1 [15] .eh_frame_hdr PROGBITS 0000000000026884 00026884 00000000000006b4 0000000000000000 A 0 0 4 [16] .eh_frame PROGBITS 0000000000026f38 00026f38 0000000000002614 0000000000000000 A 0 0 8 [17] .data.rel.ro PROGBITS 000000000002a5c0 000295c0 00000000000008ac 0000000000000000 WA 0 0 32 [18] .dynamic DYNAMIC 000000000002ae70 00029e70 0000000000000170 0000000000000010 WA 5 0 8 [19] .got PROGBITS 000000000002afe0 00029fe0 0000000000000010 0000000000000008 WA 0 0 8 [20] .got.plt PROGBITS 000000000002b000 0002a000 0000000000000050 0000000000000008 WA 0 0 8 [21] .data PROGBITS 000000000002b060 0002a060 0000000000000f98 0000000000000000 WA 0 0 32 [22] .bss NOBITS 000000000002c000 0002aff8 0000000000000190 0000000000000000 WA 0 0 32 [23] .note.stapsdt NOTE 0000000000000000 0002aff8 00000000000003e0 0000000000000000 0 0 4 [24] .gnu_debuglink PROGBITS 0000000000000000 0002b3d8 0000000000000010 0000000000000000 0 0 4 [25] .shstrtab STRTAB 0000000000000000 0002b3e8 00000000000000ec 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) $ readelf -x .gnu_debuglink /usr/lib/x86_64-linux-gnu/ld-2.29.so Hex dump of section '.gnu_debuglink': 0x00000000 6c642d32 2e32392e 736f0000 bd0ca587 ld-2.29.so......