[PATCH] Runtime support for the indirect function call checker.

Richard Smith richard at metafoo.co.uk
Fri Oct 18 18:10:34 PDT 2013



================
Comment at: lib/ubsan/lit_tests/Misc/deduplication.cpp:1
@@ -1,2 +1,2 @@
-// RUN: %clang -fsanitize=undefined %s -o %t && %t 2>&1 | FileCheck %s
+// RUN: %clang --driver-mode=g++ -fsanitize=undefined %s -o %t && %t 2>&1 | FileCheck %s
 // Verify deduplication works by ensuring only one diag is emitted.
----------------
Do we really need the --driver-mode=g++ here? If that's actually necessary, I think it should be part of %clang: %clang is supposed to be the g++-style driver.

================
Comment at: lib/ubsan/lit_tests/TypeCheck/function.cpp:1
@@ +1,2 @@
+// RUN: %clang --driver-mode=g++ -fsanitize=address,function %s -O3 -o %t
+// RUN: %t 2>&1 | FileCheck %s
----------------
Why do you need ASan here? For symbolization?

It'd be great to provide a clean mechanism to enable symbolization for UBSan (maybe parse the environment variable when we first emit a diagnostic).

================
Comment at: lib/ubsan/ubsan_handlers.cc:277-281
@@ +276,7 @@
+    << FName << Data->Type;
+  if (Info.file) {
+    Diag(SourceLocation(Info.file, Info.line, Info.column), DL_Note,
+         "%0 defined here")
+      << (Info.function ? Info.function : "(unknown)") << Data->Type;
+  }
+}
----------------
If we couldn't resolve the pointer, it'd be great to emit a note pointing at the `ModuleLocation` of the function (or, failing that, the `MemoryLocation`). Please factor out the second half of `__ubsan::getCallerLocation` and use it here.


http://llvm-reviews.chandlerc.com/D1339



More information about the llvm-commits mailing list