http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680
Bug ID: 58680
Summary: Spurious warnings from libasan
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: y.gribov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 30975
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30975&action=edit
Repro
I've found that Sanitizer will sometimes report a warning about failed
interceptions of libc functions.
$ ~/install/gcc-master/bin/gcc prog.c -fsanitize=address -DGEN_PLT
$ LD_LIBRARY_PATH=~/install/gcc-master/lib64:$LD_LIBRARY_PATH
ASAN_OPTIONS=verbosity=1 ./a.out
==30654== Parsed ASAN_OPTIONS: verbosity=1
==30654== AddressSanitizer: failed to intercept 'memcpy'
==30654== AddressSanitizer: libc interceptors initialized
...
After small and inspiring investigation I've found out that this warning is
caused by check for successful interception of memcpy in
libsanitizer/asan/asan_interceptors.cc:676:
ASAN_INTERCEPT_FUNC(memcpy);
Apart from other actions, this macro verifies that memcpy and
__interceptor_memcpy resolve to the same address. Unfortunately this does not
happen if main executable takes address of memcpy. In that case ld.so will
resolve memcpy to the address of corresponding PLT entry in executable. This
won't cause any problem (because PLT entry will eventually call Asan's memcpy)
but will make libsanitizer think that it has failed to override memcpy.
This problem could be worked around by compiling with -static-libasan because
in this case memcpy will be resolved to __interceptor_memcpy at link time (i.e.
statically). AFAIK Clang uses static libsanitizer by default so they probably
never ever faced this problem.
I suggest that we either remove the warning or make the check in
ASAN_INTERCEPT_FUNC more sophisticated so as to support dynamic libsanitizer.
-Y
