|
From: Christopher S. <csw...@sy...> - 2010-03-12 18:17:12
|
Christopher Swanson <cswanson <at> sysdel.com> writes: > > Hi, > > I'm running a Fedora 12 base with a new toolchain recently compiled: gcc 4.4.2, > glibc 2.10.1, and binutils 2.19 on x86_64. Kernel 2.6.33 recompiled. Valgrind > 3.5.0 recompiled with new toolchain. > > Valgrind wants a non-stripped ld.so. However, this is what the /usr/bin/file > command says about ld-linux-x86-64.so.2: > > $ file /usr/local/tools-0.0.2/lib/ld-2.10.1.so > /usr/local/tools-0.0.2/lib/ld-2.10.1.so: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), dynamically linked, not stripped > > Also, > > nm -a /usr/local/tools-0.0.2/lib/ld-2.10.1.so > > 000000000021cb20 b .bss > 0000000000000000 n .comment > 000000000021c040 d .data > 000000000021bbe0 d .data.rel.ro > 0000000000000000 N .debug_abbrev > 0000000000000000 N .debug_aranges > 0000000000000000 N .debug_info > 0000000000000000 N .debug_line > 0000000000000000 N .debug_loc > 0000000000000000 N .debug_pubnames > 0000000000000000 N .debug_ranges > 0000000000000000 N .debug_str > > Hence, I assume the debug info is present. > > valgrind error: > > 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 > > What is valgrind trying to find that it can't? I am delighted to share that John Reiser's suggestion worked. I had to patch glibc-2.10.1/elf/Makefile to include strlen.c to be compiled into rtld-strlen.os and then subsequently include the new file into ld.so. Here is the patch: 288c288,289 < mv -f $@T $@ --- > cat $@T | awk '{ if ( $$0 == "rtld-string +=strnlen.os" ) print \ $$0"\nrtld-string +=strlen.os"; print $$0 }' > $@TT > mv -f $@TT $@ 311a313 > /home/cswanson/devel/gcc-4.4.2-glibc-2.10/glibc-pass1/build/string/strlen.os \ Some formatting may need to be done due to this web form's 80 character limit, but it's simple and easily understood. I would enjoy to thank everybody who read and participated with my inquiry. I learned a great deal about glibc. Chris Swanson > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > |