[PATCH] [compiler-rt] Implement AddressSanitizer suppressions

[Kuba Brecka]

I totally agree that `asan_interceptor` shouldn't take a stack trace or symbolize anything, and also that we should not use suppressions for instrumented code. We only want suppressions to be used for code that you can't easily modify and recompile, like system or 3rd party libraries, which are always un-instrumented. You're right that the naming of the suppression types should be improved to make it clear that it only affects interceptors.

However, I think having just `asan_interceptor` and `called_from_lib` (which only matches the library of the immediate caller) is too coarse-grained. For example, the http://crbug.com/162461 (OpenCL overflow on Mac) was being suppressed by disabling all memcmp, memcpy, memmove, memset interceptors and that disables much more checks than it's necessary and prevents discovery of other bugs. Being able to suppress with just `asan_interceptor` and `called_from_lib` sounds like having the same issue: Disabling memcpy interceptor is way too much, just as skipping all checks for the OpenCL library. Also, `called_from_lib` is only checking the immediate caller, which in a lot of cases could be a general system library, like CoreFoundation, and ignoring this whole library is again an overkill.

I'm not looking for a temporary solution to suppress a specific bug. I'd like to have a generic mechanism that users can use when they hit a bug in code they don't own, while minimizing the impact on detection of other bugs. I know that we want to force users to *fix* bugs instead of suppressing them, but we already have things like `replace_intrin=0` or `replace_str=0`.

I understand the performance concerns and possibly a huge impact of doing symbolication just to be able to match suppressions, but note that I'm not suggesting doing any additional work for the common case, I'm only talking about situations where we were about to crash the program anyway. If I understand correctly, LibIgnore is specially optimized, because TSan uses it for *every* interceptor call, not just when it detects a race. For suppressions that take place just before a report is printed, TSan also symbolizes the stack(s) and then look for suppressions in these.

It also doesn't sound to me that we're *degrading* performance, since again we're only talking about situations where ASan would currently crash the program.

http://reviews.llvm.org/D6280