[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...
--kcc On Fri, Nov 22, 2013 at 10:34 PM, Jakub Jelinek <ja...@redhat.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 <ja...@redhat.com> 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 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. > > 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
