|
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? |