[PATCH] [compiler-rt] Implement AddressSanitizer suppressions

Kuba Brecka kuba.brecka at gmail.com
Thu Dec 4 17:03:23 PST 2014


>>! In D6280#25, @samsonov wrote:
> But wait, how do you *enforce* that suppressions don't kick in if these functions are called from instrumented code? IIRC if the user writes memset() and we build it with Clang, it may or may not be turned into intrinsic and replaced with __asan_memfoo().

Oh, I see what you mean. I thought it was about intrinsic vs. inlined, but it's about intrinsic vs. regular function call. Ok, I think I'll change the test case to just check for direct memory accesses.

================
Comment at: lib/sanitizer_common/sanitizer_suppressions.cc:27
@@ -27,1 +26,3 @@
+    "deadlock", "vptr_check", "interceptor_name", "interceptor_via_function",
+    "interceptor_via_library"};
 
----------------
earthdok wrote:
> My $.02: we have "called_from_lib" and "interceptor_via_library". We also have "interceptor_via_function" here and "fun" in the blacklist syntax. Maybe use "lib" and "fun" everywhere for consistency?
I don't necessarily disagree, but I'd like to point out that they work differently:
* interceptor_via_library ... suppresses interceptors only and matches library anywhere on the stack
* interceptor_via_function ... suppresses interceptors only and matches a function name anywhere on the stack
* called_from_lib ... also interceptors only, but only checks the topmost frame on the stack

Also, we should keep the "interceptor" in the name to indicate that these suppressions work only on interceptors, and not instrumented code (other suppression types work even on instrumented code).

http://reviews.llvm.org/D6280






More information about the llvm-commits mailing list