http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #42 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Jakub Jelinek from comment #41)
> It will work with LD_PRELOAD=libasan.so.0.
I was under the same impression. Unfortunately this seems to fail if executable
takes address of libc API (that's not an infrequent situation). I can't outline
all the details right now but this results with asan's dlsym returning address
of .plt entry in executable rather than libc symbol and .plt itself resolving
to asan wrapper.
I agree that there are some situations where this works but semantics becomes
too tricky (IMHO of course).
> 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).
Hm, this looks like a dangerous path. Should we assume that malloc should
necessarily come from libc? What if app itself overrides malloc? That's not to
mention that kcc is unlikely to make this change in upstream libsanitizer.
-Y
