|
From: <sv...@va...> - 2007-01-16 22:04:52
|
Author: sewardj Date: 2007-01-16 22:04:50 +0000 (Tue, 16 Jan 2007) New Revision: 6528 Log: Merge r6526 (Intercept _intel_fast_memcpy in the main executable.) Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2007-01-16 = 22:03:54 UTC (rev 6527) +++ branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2007-01-16 = 22:04:50 UTC (rev 6528) @@ -406,7 +406,17 @@ MEMCPY(m_libc_so_star, memcpy) MEMCPY(m_ld_so_1, memcpy) /* ld.so.1 */ =20 +/* icc9 blats these around all over the place. Not only in the main + executable but various .so's. They are highly tuned and read + memory beyond the source boundary (although work correctly and + never go across page boundaries), so give errors when run natively, + at least for misaligned source arg. Just intercepting in the exe + only until we understand more about the problem. See + http://bugs.kde.org/show_bug.cgi?id=3D139776 + */ +MEMCPY(NONE, _intel_fast_memcpy) =20 + #define MEMCMP(soname, fnname) \ int VG_REPLACE_FUNCTION_ZU(soname,fnname) \ ( const void *s1V, const void *s2V, SizeT n ); \ |