On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
> >Do you have LD_PRELOAD set in the environment?
> I don't.
> >If not, can you cut'n'paste the large-func-test-1.exe command line
> >and run it with the given LD_LIBRARY_PATH under ldd? Jakub
> Sure. This is what I get:
>
> linux-vdso.so.1 (0x00007fffee578000)
> libasan.so.1 =>
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/libasan.so.1
> (0x00007f41610c7000)
> libstdc++.so.6 =>
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6
> (0x00007f4160db6000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f4160ab3000)
> libgcc_s.so.1 =>
> /home/paolo/Gcc/svn-dirs/trunk-build/gcc/libgcc_s.so.1
> (0x00007f416089c000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f41604ed000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41602cf000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f41600cb000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f4161ff3000)
Kostya, guess you should ignore the vDSO.
I'd say the test is useless anyway, if you really want to do some
quick sanity check, much better would be just dlsym a couple of
interesting symbols to verify that libasan.so.1 is ahead
of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
you want to override). Otherwise libasan apps will simply stop
working altogether if LD_PRELOAD is set, to whatever library,
even if it doesn't define any symbols you care about.
I'd verify that malloc, memcpy, pthread_create, operator new
all resolve to the libasan.so.1 copy (if all those have local aliases,
just compare what dlsym returns with those local aliases).
Typically people in LD_PRELOAD override malloc (which we want to diagnose),
or far more rarely stringops (e.g. memstomp, also undesirable).
Jakub
