Bug 349828

This seems to be cause by the fact that in glibc 2.20 powerpc enabled MEMCPY_OK_FOR_FORWARD_MEMMOVE (commit glibc-2.19-778-gd6f68bb) which makes memmove just call memcpy in some cases. Normally this would not be an issue. valgrind would already have intercepted memmove so the memmove -> memcpy call wouldn't be there. But... this is a memmove copy in ld.so, which valgrind doesn't intercept. Valgrind does intercept memcpy in ld.so however. So now we see a memmove that calls into memcpy and valgrind complains that memcpy has overlaps.

This was "fixed" in commit glibc-2.21-50-gb269211 for glibc 2.22. Which renames the powerpc memmove to __ppc_memmove for internal calls. So this only impacts glibc 2.20 and 2.21 on poerpc64. Luckily ld.so has its own special version/name on ppc.

Proposed fix:

diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
index d4e5449..0f366bf 100644
--- a/shared/vg_replace_strmem.c
+++ b/shared/vg_replace_strmem.c
@@ -1141,6 +1141,10 @@ static inline void my_exit ( int x )
 #if defined(VGO_linux)
  MEMMOVE(VG_Z_LIBC_SONAME, memmove)
  MEMMOVE(VG_Z_LIBC_SONAME, __GI_memmove)
+ /* See bug #349828 Override for ld64.so.1 like memcpy, because for some
+    arches MEMCPY_OK_FOR_FORWARD_MEMMOVE is set, which might cause memmove
+    to call memcpy.  */
+ MEMMOVE(VG_Z_LD64_SO_1, memmove)
 
 #elif defined(VGO_darwin)
 # if DARWIN_VERS <= DARWIN_10_6

valgrind svn r15397