Created attachment 33034 [details] valgrind-x86_64-ldso-strlen.patch Valgrind isn't able to understand the new SSE2 optimized x86_64 strlen in current CVS glibc and reports thousands of issues even on /bin/true. I'm attaching a fix.
thank you for the patch, works with Fedora 11, just have to remember to apply it
Tested on Fedora 11 and committed as r10402.
Reopening... Julian said in response to the commit email: "Unfortunately causes memcheck to be completely unusable on openSUSE 11.0, since there's no such symbol. I'll investigate. [I suspected that this patch would have that effect, which is why I didn't merge it. But I should have said so on the bug report, true.]"
It also breaks everything on my Ubuntu 64-bit box. Here's the message: 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 fix: install glibc's debuginfo package on this machine. valgrind: valgrind: Cannot continue -- exiting now. Sorry. I'm going to back out r10402.
I just tested valgrind on my 64bit Gentoo machine (glibc 2.10.1). Valgrind 3.4 registers 4000+ errors in /bin/true, SVN valgrind (rev 10418) does work fine.
Guess those distros strip away symbols from ld-linux-x86-64.so.2. The add_hardwired_spec call could be called with NULL last argument to say it is not mandatory perhaps, it is really mandatory on x86-64 only when using glibc 2.10 and later. I just wonder how can ppc32 and ppc64 valgrind work on SUSE/Ubuntu if ld.so.1 is stripped there, strlen in ld.so.1 is also required there. Are they stripping symbols just on x86/x86-64 and not on ppc/ppc64?
(In reply to comment #6) > I just wonder how can ppc32 and ppc64 valgrind work on SUSE/Ubuntu if ld.so.1 > is stripped there, strlen in ld.so.1 is also required there. Are they > stripping symbols just on x86/x86-64 and not on ppc/ppc64? The test whether strlen() has been redirected does not work properly on the openSUSE ppc editions. See also https://bugs.kde.org/show_bug.cgi?id=182474.
(In reply to comment #6) > I just wonder how can ppc32 and ppc64 valgrind work on SUSE/Ubuntu if ld.so.1 > is stripped there, strlen in ld.so.1 is also required there. It's simple -- valgrind doesn't work on those platforms. ppc valgrind is unusable on opensuse 11.x ppc32/64 and 10.3 too, iirc. This is basically a serious problem. We need to have distros not strip ld.so. If distros continue to strip ld.so then at some point I imagine we will have to say that we can no longer support Valgrind on those distros.
> Valgrind isn't able to understand the new SSE2 optimized x86_64 strlen in > current CVS glibc and reports thousands of issues even on /bin/true. Do these problems occur also on x86 (32-bit) glibc-2.10.x, or only 64-bit?
Making the strlen redir for amd64-linux non-mandatory, as per Comment #6. Also, changing the failure message to the following (compare against Comment #4): 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. valgrind: valgrind: Cannot continue -- exiting now. Sorry.
Revised version of patch committed as r10689. It makes the redirection mandatory, but only on glibc-2.10 and later. JJ (or other Fedora person), can you pls verify if this works for you?
Closing this, given that I think it's fixed and I haven't heard anything to the contrary.
I am seeing the "must-be-redirected-function" for strlen on my amd64 gentoo boxes with glibc 2.10.1 and valgrind 3.5.0. I have taken the short term solution and built glibc with debugging info installed, but I am unsure what the proper fix is. This is not required on my 32 bit Gentoo boxes.
I got the same problem on my amd64 gentoo box. Debug symbols are there, glibc-1.11.2, valgrind 3.5 Since this bug is marked "RESOLVED FIXED" I understand there must be a known solution. Is there any? Can I do something to get valgrind to work? Cheers, Stephan
(In reply to comment #14) It is not fixed in 3.5, it is fixed on the trunk. See http://www.valgrind.org/downloads/repository.html for details on how to check out and build it.
Julian, thanks for the hint. Alas, I'm sitting behind a http only packet filter here and can't access svn. Are there any snapshots? Or maybe that revised patch against 3.5? Or a http svn web interface? Cheers, Stephan
(In reply to comment #10) > 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 I am getting this ^^^ failure now again with glibc-2.12.2 on x86_64 Linux. When glibc is compiled by gcc-4.5.2 with -march=nocona, all calls of strlen() in ld-linux-x86-64.so.2 are optimized out and the symbol is hence not available from outside: # nm /lib64/ld-2.12.2.so | grep '\bstr' 0000000000015320 t strchr 00000000000153a0 t strcmp 00000000000153d0 t strnlen 0000000000014203 t strsep I recompiled glibc with -fno-builtin-strlen and valgrind started to work again.