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

On Fri, Nov 22, 2013 at 10:19 AM, Alexey Samsonov <> wrote:
> On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek <> wrote:
>> On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
>> > I will try.
>> 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.

Personally, I would recommend that you simply copy the libbacktrace
sources into your sources.  It's less than 7000 lines of C code.  You
can update the sources periodically as needed.  In other words, pretty
much how the sanitizer code is handled, only in the other direction.

Note that libbacktrace is not currently installed, so you can't expect
-lbacktrace to work in general if you don't include the sources.


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