http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #40)
> >> Jakub Jelinek wrote:
> >> Previously ASAN would often work
> >> even when binary wasn't linked with -fsanitize=address,
> >> though sometimes it wouldn't
> >
> > Yury Gribov wrote:
> > this patch may result in reduced functionality
> > i.e. some projects may start failing.
>
> Actually do we have an example of unsanitized binary working with sanitized
> dynamic lib? Currently I see all REAL() macro resolving to NULL in this case
> (and then causing segfaults in __asan_init).
>
> -Y
It will work with LD_PRELOAD=libasan.so.0. In any case, the Linux
__interception::GetRealFunctionAddress should be probably improved, it blindly
assumes that the libc/libpthread version of the functions must come after the
libasan ones in the search scope, while it can come before them. IMHO if dlsym
(RTLD_NEXT, ...) fails, then it should retry with dlopen ("libc.so.6",
RTLD_NOLOAD); and dlsym on the result of that if it didn't fail (resp.
libpthread.so.0 for pthread_* of course).
