On Thu, Jun 6, 2013 at 12:26 PM, Andrew Pinski <pins...@gmail.com> 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.
for asan/tsan/msan/lsan the reason is that C++ is a better language (in the author's humble opinion :). For ubsan, I think the reason is the same, plus ubsan shares some C++ code with asan/tsan/msan/lsan. As for libstdc++, I completely agree, we don't want to depend on it, and we don't. None of sanitizer run-times uses C++ features that require libstdc++ --kcc > > Also it seems easy enough to write a GCC specific runtime that does > not depend on the rest of libsanitizer stuff anyways. > > Thanks, > Andrew Pinski
