http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #42)
> (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.
How could dlsym (RTLD_NEXT, ...) from a shared library return address of .plt
in the executable? The executable is always first in the search scope, and
RTLD_NEXT means start looking from the current shared library (not including
it) onwards.
> > 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.
Why? If dlsym returns NULL, then libasan is last in the search scope for those
symbols, so even if malloc etc. is overridden, the overriding comes earlier in
the search scope. Of course, without binary being linked with -lasan and
without LD_PRELOAD=libasan.so.0, the checking features of libasan can be very
limited, the main point is if you have some library you built with asan for
some reason and need to run some other binary against that library, ideally it
would just work, even if it doesn't find all the issues in the shared library.
