This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alexey Samsonov <samsonov at google dot com>
- Cc: Konstantin Serebryany <kcc at gcc dot gnu dot org>, Ian Lance Taylor <iant at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 25 Nov 2013 16:02:03 +0100
- Subject: Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer
- Authentication-results: sourceware.org; auth=none
- References: <20131118133930 dot GA892 at tucnak dot redhat dot com> <CAGSYnCMV=Sa6sNq5W-WcB-+iH_f3wwcQyBZ8HMEKsEW7VamHxA at mail dot gmail dot com> <CAGSYnCOs6BHEqfhoBdpF0AEODHhbhLENyWGy_DrObVnUv+js2g at mail dot gmail dot com> <20131118162342 dot GH892 at tucnak dot redhat dot com> <CAGSYnCPcGeYB7EEw=jAFf6h-gc2wJi0hqeZLDPEfmKOjq3FWAA at mail dot gmail dot com> <20131119153350 dot GW892 at tucnak dot redhat dot com> <20131119164221 dot GZ892 at tucnak dot redhat dot com> <CAGSYnCNYcAfhN6k-JFkBbnub2U6=x_VYCuH2K7VhSUf7HZ2FCQ at mail dot gmail dot com> <20131122183452 dot GI892 at tucnak dot redhat dot com> <CAGSYnCOqf4Yz0ji+tGnioAN1HF8iuHVLpq+sBRO9h6qYnwU=2A at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Nov 25, 2013 at 06:53:59PM +0400, Alexey Samsonov wrote:
> > In GCC, libbacktrace is built as a libtool convenience library only and
> > then linked into whatever libraries want to use it. So indeed, the plan
> > is to link libbacktrace.la into libasan.so.1.0.0 and libasan.a
> > (and the earlier GCC patch I've posted included corresponding toplevel
> > configure/Makefile bits and libsanitizer Makefile/configure changes to make
> > it happen). E.g. libgo.so.* links libbacktrace.la into itself too.
> > So, for GCC user experience, things will work automatically.
> Good. Note, however, that you'd need at least two versions of
> libbacktrace - 32-bit and 64-bit.
In GCC you get that automatically (unless --disable-multilib, but then you
don't get 32-bit libsanitizer either say on x86_64-linux).
> > it means finding some way in the build system/configure to detect
> > or request libbacktrace availability (for libraries not included in
> > GCC tree GCC's configure typically uses --with-<package>=<path>
> > or --with-<package>-lib=<path>/--with-<package>-include=<path>) and just
> > link against it and you'd just unpack/configure/build libbacktrace
> > on one of your test bots.
> We indeed can add support for detecting presence of libbacktrace
> binaries and headers
> when we configure a build tree. But to "just link against it" we have
> to either link against it in Clang
> driver (I don't think we should add support for it), or link against
> it in all the places where we build something
> with "-fsanitize=foo", and there are quite a few of them.
Or change the rules for creation of *sanitizer_common.*a, so that you
link the libbacktrace.la convenience library into it (if configure found
it). If you build it using libtool/automake, you get it automatically,
otherwise you can e.g. using ar unpack libbacktrace.a and note the filenames
of the object files from it, then add those to the ar command line for
creation of *sanitizer_common.*a.
> As for redirecting libc calls from libbacktrace to our internal
> versions (or interceptors) -
> if it works fine for our toy tests (which is the case), I suggest to
> wait for the actual problems gcc
> users may discover. If there will be need in compiling a separate
> sanitizer-specific version of libbacktrace,
> or providing an additional layer between libbacktrace and sanitizer
> runtimes, or both, this could probably
> be done in gcc version of the runtime only (w/o modifying any existing
> source files, only adding standalone gcc-specific stuff).
Sure, worst case you keep it untested in your LLVM copy of libsanitizer
and we'll just need to fix it up during merges if something breaks.
If it will be used for GCC (and we have a P1 bug so it is a release blocker
if llvm-symbolizer is still used), then it will be tested there.