I can confirm this error, as I wanted to report it myself.
I use Gentoo GNU/Linux with glibc 2.14.1 compiled with splitdebug enabled and even with basic optimizations strlen gets stripped out:
$ nm /usr/lib/debug/lib/ld-2.14.1.so.debug | grep "\bstr"
00016eb0 t strchr
00017020 t strcmp
00017048 t strcpy
00017070 t strnlen
00014e97 t strsep
After a lot of investigations I came up with conclusion, that strlen shouldn't be looked at by valgrind at all, as this causes more trouble than it's worth, as evident not only by this bug, but by false-positives like https://bugzilla.redhat.com/show_bug.cgi?id=678518
Also: because my system benefits heavily from SSE enhancements, forcing no builtin strlen causes huge penalty on overall performance of my apps (dunno about others, perhaps whole system benefits), so currently I am left with unusable valgrind. This bug should have higher priority as it is absolute blocker for me.
I can confirm this error, as I wanted to report it myself.
I use Gentoo GNU/Linux with glibc 2.14.1 compiled with splitdebug enabled and even with basic optimizations strlen gets stripped out:
$ nm /usr/lib/ debug/lib/ ld-2.14. 1.so.debug | grep "\bstr"
00016eb0 t strchr
00017020 t strcmp
00017048 t strcpy
00017070 t strnlen
00014e97 t strsep
After a lot of investigations I came up with conclusion, that strlen shouldn't be looked at by valgrind at all, as this causes more trouble than it's worth, as evident not only by this bug, but by false-positives like https:/ /bugzilla. redhat. com/show_ bug.cgi? id=678518
Also: because my system benefits heavily from SSE enhancements, forcing no builtin strlen causes huge penalty on overall performance of my apps (dunno about others, perhaps whole system benefits), so currently I am left with unusable valgrind. This bug should have higher priority as it is absolute blocker for me.