This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer

[I beg my pardon if this has already been discussed here]
Does libbacktrace call any functions we intercept (malloc, memset,
memcpy, strlen, etc)?
If so, they will have to be un-intercepted there.
Our hermetic llvm-symbolizer took as so much work for a reason. :(
And doing this work for libbacktrace w/o any additional functionality
for us is kind of sad...


On Fri, Nov 22, 2013 at 10:34 PM, Jakub Jelinek <> 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 <> 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
>> system.
>> 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
>> it).
>> 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 into 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.* links into itself too.
> So, for GCC user experience, things will work automatically.
> 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,
> 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.
>         Jakub

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]