This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Yury Gribov <y dot gribov at samsung dot com>, Andrew Pinski <pinskia at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, Marek Polacek <polacek at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Thu, 22 May 2014 21:54:37 +0200
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdzNff1SK-BT9vYBdeX1mFeMKw0eTvaLb63qd8e4ow88NA at mail dot gmail dot com> <b75522cf-9cc0-4e53-a497-f939a512259a at email dot android dot com> <20140522094737 dot GZ10386 at tucnak dot redhat dot com> <CAGQ9bdy+j4+-immgKGdUHwc6au_jRzxCnuy=ehKZozbq6Ks2Qw at mail dot gmail dot com> <20140522110348 dot GC10386 at tucnak dot redhat dot com> <537E4427 dot 4060006 at oracle dot com> <20140522190200 dot GJ10386 at tucnak dot redhat dot com> <537E4A10 dot 8090205 at oracle dot com> <20140522191528 dot GK10386 at tucnak dot redhat dot com> <537E5345 dot 2030804 at oracle dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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