This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer
- From: Alexey Samsonov <samsonov at google dot com>
- To: Jakub Jelinek <jakub at redhat 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 18:53:59 +0400
- 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>
On Fri, Nov 22, 2013 at 10:34 PM, Jakub Jelinek <email@example.com> wrote:
> On Fri, Nov 22, 2013 at 10:19:02PM +0400, Alexey Samsonov wrote:
>> On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek <firstname.lastname@example.org> wrote:
>> > Ok, here it is (untested though, because libsanitizer in gcc is older and I
>> > don't have spare cycles to play with llvm).
>> > Guess you need to write it up into compiler-rt buildsystem somehow,
>> > and for testing add
>> > -DSANITIZER_LIBBACKTRACE -I..../srcdir_of_libbacktrace -I..../builddir_of_libbacktrace -L..../builddir_of_libbacktrace/.libs -lbacktrace
>> > This is against current libbacktrace (r205028 or later, before that
>> > the syminfo callbacks had one less argument).
>> Do you have an idea of how the libbacktrace symbolizer should look to
>> the end user (if the static runtime was built with
>> -DSANITIZER_LIBBACKTRACE)? I see the following options, none of which
>> looks nice:
>> 1) Force the user to provide -L/path/to/libbacktrace -lbacktrace at
>> link time (otherwise one will see link errors like "undefined symbol:
>> backtrace_create_state"). Certainly this is a bad user experience.
>> 2) Make -fsanitize=address link flag imply "-lbacktrace" as we do for
>> libpthread, librt etc. But libbacktrace may not be installed in the
>> 3) Pull libbacktrace.a inside libasan.a. This means we should teach
>> the build system to merge two archives (or have access to backtrace
>> sources at build time and recompile them ourselves). This is doable,
>> but kind of ugly and leads to funny consequences - we'll fail to build
>> libbacktrace itself with ASan (or, arguably, any program which uses
>> I ask this because I'm slightly afraid libbacktrace symbolizer will be
>> pretty undertested in the llvm tree and we may break it without
>> noticing. Building it is not a problem, but making all the tests "just
>> work" with it is harder.
> 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.
> As Ian said, libbacktrace right now is not maintained as it's own separate
> entity that would be individually installable etc. So, for testing
> in LLVM, if you don't want to copy over libbacktrace sources in there,
I don't think we want to copy libbacktrace sources into LLVM and maintain it :(
> 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.
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).
That said, I'm going to do a basic sanity test of Jakub's patch
applied to LLVM trunk (test that it build fine with and w/o
and works if we add -lbacktrace in the latter case), and commit it, so
that we can merge this into gcc. Once again, sorry for the delays.
Alexey Samsonov, MSK