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 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 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.
> 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 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.


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