[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