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? 



------------------------------------------------------------------------------
Download Intel&#174; 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
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to