http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #45 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Jakub Jelinek from comment #44)
> How could dlsym (RTLD_NEXT, ...) from a shared library return address of
> .plt in the executable?
Ok, I'm an idiot. The problem I faced was caused by global `export
LD_PRELOAD=libasan.so.0' in my /etc/profile. It turns out that if we preload
asan for executable which does not load any sanitized lib, __asan_init_v1 will
not get called and thus wrappers will not be properly initialized:
$ gdb a.out
Reading symbols from /mnt/scratch/ygribov/vdtools/tests/signal/a.out...done.
(gdb) set env LD_PRELOAD /home/ygribov/install/gcc-master/lib64/libasan.so.0
(gdb) b __asan_init_v1
Function "__asan_init_v1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__asan_init_v1) pending.
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff4e4fa62 in signal () at
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_interceptors.cc:133
#2 0x0000000000400523 in main ()
Should probably be easy to fix by adding __asan_init_v1 to a list of libasan's
initializers. Persuading kcc to do this will be tricky though.
> > > 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.
Agreed but this overriding does not necessarily come from libc. What if
application or some intermediate shared lib overloads malloc? Mixing overloaded
and libc's allocators may easily cause havoc if allocated pointers are passed
across shared lib boundaries.
> Of course, without binary being linked with
> -lasan and without LD_PRELOAD=libasan.so.0,
Small correction: IMHO there is very little chance that unsanitized executable
is going to work without LD_PRELOAD (because dlsym calls will return NULLs).
> 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.
Ok, I see your point. I wish we had some way to provide useful diagnostic
messages though. Current situation (mysterious segfaults in initialization
code) is too inconvenient for ordinary user.
-Y
