[PATCH] [UBSan] Embed UBSan into ASan runtime (compiler-rt part).

[Alexey Samsonov]

Added -lc++abi as Kuba suggests. If you confirm that CMake/Makefile build works and passes tests on Apple now, I would like to submit this. If problems with two ASan tests on Jenkins build will re-appear, we will address this issue separately.


================
Comment at: lib/ubsan/CMakeLists.txt:43
@@ +42,3 @@
+        SOURCES ${UBSAN_STANDALONE_SOURCES}
+        CLFAGS ${UBSAN_STANDALONE_CFLAGS})
+
----------------
kubabrecka wrote:
> Typo "CLFAGS" -> "CFLAGS".
Done

================
Comment at: lib/ubsan/ubsan_init.cc:52
@@ +51,3 @@
+  SpinMutexLock l(&ubsan_init_mu);
+  CHECK_NE(UBSAN_MODE_PLUGIN, ubsan_mode);
+  if (ubsan_mode == UBSAN_MODE_UNKNOWN)
----------------
kcc wrote:
> ygribov wrote:
> > Note that this will probably break GCC's dynamic UBSan runtime (e.g. when one part of the app is A-sanitized and another is UB-sanitized).
> It may, and we will need to do something with this, most likely forbid some of the combination. 
> The more combinations we support the more complex the code is, and we can not afford that. 
Right. I'd even say that we deliberately forbid linking one .so with ASan, and another .so with UBSan - this setup might not cause visible problems for a while, but is inherently broken - you can't link in two copies of sanitizer_common runtime into a process, and there can be issues with initialization order, flag parsing, etc.

================
Comment at: make/platform/clang_darwin.mk:279
@@ -279,1 +278,3 @@
+                              $(AsanDynamicFunctions) \
+															$(UbsanFunctions) $(UbsanCXXFunctions)
 
----------------
ygribov wrote:
> Looks like you use tabs here and below which is inconsistent with existing code.
Fixed.

http://reviews.llvm.org/D8646

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/