On Thu, Jun 06, 2013 at 01:26:06AM -0700, Andrew Pinski wrote: > On Thu, Jun 6, 2013 at 1:21 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote: > >> If we are going to import the ubsan run-time from LLVM's > >> projects/compiler-rt/lib/ubsan, > >> we may also need to update the contents of > >> libsanitizer/sanitizer_common and keep them in sync afterwards. > >> (ubsan shares few bits of code with asan/tsan/msan) > >> The simplest way to do that is to extend libsanitizer/merge.sh > > > > Sure. I've done so far just a partial merge by hand (only 3 changed files > > for the minimum of changes required to get ubsan to build), and have tested > > just > > that it compiles, not that libubsan actually works. > > > > P1 patch is the toplevel stuff to add ubsan into GCC libsanitizer, plus > > ubsan/Makefile* and ubsan/libtool-version (i.e. gcc owned files). > > P2 is the actual merge of the ubsan files. > > P3 is something I'd propose for ubsan upstream, without it g++ warns about > > __int128 in -pedantic mode. > > Is there a reason why ubsan runtime in C++? That seems like a bad > idea to require linking against libstdc++ when doing development of a > C only program.
-fsanitize=undefined etc. are debugging modes, not something meant for release versions of programs, I think it is not a big deal. C++ is implementation language for the libraries, why exactly we actually link libasan and libtsan against -lstdc++ I don't really remember, maybe we don't have to, it is compiled with -fno-exceptions and doesn't use any libstdc++ symbols. libubsan apparently has two files which actually use some libstdc++ symbols and are for some C++ sanitization. BTW, all the libs link against -ldl too (not that big a deal) and -lpthread (IMHO more serious problem than -lstdc++). > Also it seems easy enough to write a GCC specific runtime that does > not depend on the rest of libsanitizer stuff anyways. We already have libasan and libtsan in gcc, ubsan is just a think layer on top of the sanitizer_common infrastructure, we'd have to write from scratch not just the handlers, but some infrastructure too, for what gain? Jakub