|
From: Christopher S. <csw...@sy...> - 2010-03-09 17:25:20
|
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? |
|
From: John R. <jr...@bi...> - 2010-03-09 18:25:03
|
> 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? The code for strlen, with the name "strlen", in ld-linux-x86-64.so.2. The code is there, and "must" be re-directed to valgrind's replacement strlen, else "false positive" errors abound [because memcheck does not understand the actual code.] Unfortunately, the code that is there has no symbol, and memcheck is too proud to look for the code by value. So memcheck gives up. Revert to the previous ld-linux-x86-64.so.2. Or, perhaps re-compile ld-linux-x86-64.so.2 with "-g", then be sure that the symbol "strlen" exists in ld-linux-x86-64.so.2. -- |
|
From: Christopher S. <csw...@sy...> - 2010-03-12 02:14:10
|
John Reiser <jreiser <at> bitwagon.com> writes: > > > 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? > > The code for strlen, with the name "strlen", in ld-linux-x86-64.so.2. > The code is there, and "must" be re-directed to valgrind's replacement > strlen, else "false positive" errors abound [because memcheck does > not understand the actual code.] Unfortunately, the code that is there > has no symbol, and memcheck is too proud to look for the code by value. > So memcheck gives up. > > Revert to the previous ld-linux-x86-64.so.2. Or, perhaps re-compile > ld-linux-x86-64.so.2 with "-g", then be sure that the symbol "strlen" > exists in ld-linux-x86-64.so.2. > I have assigned '-g' to the CFLAGS variable, so I have focused on the inclusion of strlen into ld-linux-x86-64.so.2. This is what I have found: The ld-2.10.1 linker is built following a particular build path involving the prefix rtld. I have tracked down the files that are used to generate the ld-2.10.1 and they seem to originate from an object file named dl-allobjs.os. This file is parsed for relevant libc.a system calls that then produces a list file called librtld.mk. After the creation of this file, the Makefile will recompile each file entry and name the object file rtld-$name.os. This new collection of object files will be linked together into the linker. I seem to have two choices: 1) Figure out a way to include the strlen call into dl-allobjs.os, or 2) Patch the makefile to add the strlen.os to the librtld.mk file. Both choices seem to have nasty possible effects, but I only have my intuition telling me that. Does anybody else have any thoughts? |
|
From: Julian S. <js...@ac...> - 2010-03-12 10:09:18
|
On Friday 12 March 2010, Christopher Swanson wrote: > John Reiser <jreiser <at> bitwagon.com> writes: > > > 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 > 1) Figure out a way to include the strlen call into dl-allobjs.os, or > 2) Patch the makefile to add the strlen.os to the librtld.mk file. Sorry, this fell through the cracks. The standard solution to these problems is simply to ask your package manager to install the debuginfo package (containing the required symbols) for glibc. I'm not sure what the package name is on Fedora. I'd guess it would match "*libc*debuginfo*" or at least "*libc*debug*". Can you find anything like that? J |
|
From: Christopher S. <csw...@sy...> - 2010-03-12 18:10:01
|
Julian Seward <jseward <at> acm.org> writes: > > On Friday 12 March 2010, Christopher Swanson wrote: > > John Reiser <jreiser <at> bitwagon.com> writes: > > > > 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 > > > 1) Figure out a way to include the strlen call into dl-allobjs.os, or > > 2) Patch the makefile to add the strlen.os to the librtld.mk file. > > Sorry, this fell through the cracks. The standard solution to these > problems is simply to ask your package manager to install the debuginfo > package (containing the required symbols) for glibc. I'm not sure > what the package name is on Fedora. I'd guess it would match > "*libc*debuginfo*" or at least "*libc*debug*". Can you find anything > like that? > > J > > ------------------------------------------------------------------------------ > 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 > Thanks Julian, In this case, I am the package manager and I am unfamiliar on the compile options to define to create the debuginfo information. I tried '-g' in CFLAGS and that does enable gdb to trace the libc functions. However, valgrind seems to want a different reference type. I am following John Reiser's suggestion to include strlen in ld.so. |
|
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 > |