https://bugzilla.redhat.com/show_bug.cgi?id=1232158
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