Bug 190429 - Valgrind reports lost of errors in ld.so with x86_64 2.9.90 glibc
Summary: Valgrind reports lost of errors in ld.so with x86_64 2.9.90 glibc
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.5 SVN
Platform: Compiled Sources Linux
: NOR major
Target Milestone: blocking3.5.0
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-23 11:35 UTC by Jakub Jelinek
Modified: 2011-05-29 18:36 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
valgrind-x86_64-ldso-strlen.patch (2.69 KB, patch)
2009-04-23 11:35 UTC, Jakub Jelinek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2009-04-23 11:35:27 UTC
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.
Comment 1 Wayne Arnold 2009-06-05 04:04:48 UTC
thank you for the patch, works with Fedora 11, just have to remember to apply it
Comment 2 Tom Hughes 2009-07-02 15:04:01 UTC
Tested on Fedora 11 and committed as r10402.
Comment 3 Nicholas Nethercote 2009-07-02 22:09:48 UTC
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.]"
Comment 4 Nicholas Nethercote 2009-07-02 22:45:49 UTC
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.
Comment 5 Henning Rogge 2009-07-09 20:17:26 UTC
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.
Comment 6 Jakub Jelinek 2009-07-13 13:39:00 UTC
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?
Comment 7 Bart Van Assche 2009-07-13 13:55:18 UTC
(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.
Comment 8 Julian Seward 2009-08-02 13:01:30 UTC
(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.
Comment 9 Julian Seward 2009-08-02 13:30:20 UTC
> 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?
Comment 10 Julian Seward 2009-08-02 14:04:57 UTC
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.
Comment 11 Julian Seward 2009-08-02 14:22:34 UTC
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?
Comment 12 Julian Seward 2009-08-07 22:31:40 UTC
Closing this, given that I think it's fixed and I haven't heard
anything to the contrary.
Comment 13 Dave Flogeras 2010-05-18 21:36:02 UTC
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.
Comment 14 Stephan Menzel 2010-06-16 09:02:59 UTC
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
Comment 15 Julian Seward 2010-06-16 09:46:43 UTC
(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.
Comment 16 Stephan Menzel 2010-06-16 09:59:30 UTC
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
Comment 17 Kamil Dudka 2011-05-29 18:36:13 UTC
(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.