http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #36 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #34) > And what is the reason why you want to duplicate the library optimization > (which for memset/memcpy etc. is highly optimized, in glibc these days > depends on the CPUs through ifunc etc.)? We do use REAL(memset) (the one that comes from dlsym) in all performance-critical places in asan/tsan/msan. Can do it lsan too if there is still a need. Due to our tangled dependencies we can not easily call REAL(memset) from sanitizer_common (see my ugly workaround that allows to call REAL(pthread_attr_getstack) from sanitizer_common: http://llvm.org/viewvc/llvm-project?rev=195441&view=rev) However, we do need fast memset/memcpy of our own in one case: hybrid instrumentation (DRASan, MSanDR). When we combine static compiler instrumentation with DynamoRIO instrumentation to handle third-party libs we need to instrument libc's memset/memmove and so we need to use internal_mem* inside our run-time. This is hairy... > I mean, for small sizes you probably don't care and then doing it inline is > fine, for larger sizes I think the interceptor has dlsym (RTLD_NEXT, > "memcpy") saved somewhere anyway, so why don't you call that function > pointer for say copying/clearing of say more than 64 bytes? lsan doesn't > even intercept memset (or does it?), thus is there a reason why it just > can't call memset directly?
