This is the mail archive of the
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail 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: Fri, 23 May 2014 09:40:44 +0200
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <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> <20140522195437 dot GN10386 at tucnak dot redhat dot com> <537EDCE4 dot 6070509 at samsung dot com> <20140523063417 dot GP10386 at tucnak dot redhat dot com> <537EF6A1 dot 8030106 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, May 23, 2014 at 11:20:01AM +0400, Yury Gribov wrote:
> >Even before this exaggerated check asan imposes far more restrictions than
> >good, and this just makes asan less usable just for fear that it wouldn't
> >work right.
> Ok, we seem to approach this from two different angles.
> I usually try to prohibit functionality that's not proven to work
> It could be later enabled if users need it.
No other shared library does anything close to that, for each such library
you can interpose any of its public symbols, either you know what you are
doing when interposing it, or it breaks.
> >That is nonsense. Early in the symbol search scope is the opposite of being
> >initialized early, on the contrary, such libraries are initialized last.
> I may be wrong but my understanding was that ld.so performs a
> reverse topological sort of dependencies and initializes them in
> that order.
> Given that libasan depends on standard libs (librt, lipthread,
> libdl, etc.) it'll be initialized after them but before user libs.
> Initializers of std libs may indeed cause problems but we at least
> make sure to initialize before arbitrary user libraries.
Just try say
LD_DEBUG=all LD_PRELOAD=libasan.so.1 /bin/bash
to see (non-instrumented bash or any of its shared libraries).
30218: object=/bin/bash 
30218: scope 0: /bin/bash ./libasan.so.1.0.0 /lib64/libtinfo.so.5 /lib64/libdl.so.2 /lib64/libc.so.6 /lib64/libpthread.so.0 /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 /lib64/libm.so.6 /lib64/ld-linux-x86-64.so.2 /lib64/libgcc_s.so.1
30218: calling init: /lib64/libpthread.so.0
30218: calling init: /lib64/libc.so.6
30218: calling init: /lib64/libgcc_s.so.1
30218: calling init: /lib64/libm.so.6
30218: calling init: /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
30218: calling init: /lib64/libdl.so.2
30218: calling init: /lib64/libtinfo.so.5
30218: calling init: ./libasan.so.1.0.0
libasan.so.1 doesn't depend on libtinfo.so.5, only bash itself does,
yet libtinfo.so.5 is constructed before libasan.so.1.