[PATCH] [compiler-rt] Implement AddressSanitizer suppressions

[Alexey Samsonov]

>>! In D6280#36, @kubabrecka wrote:
> I have tried this patch on Linux and I've seen this test failure:
> 
> 	FAIL: AddressSanitizer64 :: TestCases/strncpy-overflow.cc (1 of 1)
> 	...
> 	/tmp/llvm/projects/compiler-rt/test/asan/TestCases/strncpy-overflow.cc:20:12: error: expected string not found in input
> 	// CHECK: {{ #1 0x.* in main .*strncpy-overflow.cc:}}[[@LINE-4]]
> 
> The reason for that is that the printed stack trace looks like this:
> 
>     #0 0x44caf2 in strncpy /tmp/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:637
>     #1 0x44cd31 in strncpy /tmp/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:637
>     #2 0x4cdfdb in main (/tmp/llvm-cmake-debug/projects/compiler-rt/test/asan/64bitConfig/TestCases/Output/strncpy-overflow.cc.tmp+0x4cdfdb)
>     #3 0x7f05b89eee64  (/lib64/libc.so.6+0x24e64)
>     #4 0x417b08 in _start (/tmp/llvm-cmake-debug/projects/compiler-rt/test/asan/64bitConfig/TestCases/Output/strncpy-overflow.cc.tmp+0x417b08)
> 
> The doubled strncpy is the issue. To fix that, I moved the GET_CURRENT_PC_BP_SP line in ACCESS_MEMORY_RANGE right to the call to __asan_report_error.

This change is fine. I've applied and tested this patch, and uncovered another nasty problem with this test case:
  LeakSanitizer-AddressSanitizer :: TestCases/suppressions_file.cc
Here's the problem: if you use LSan+ASan we still want to match suppressions specified in LSAN_OPTIONS. But after you change we have the following behavior:
  # __asan_init is called, it parses ASAN_OPTIONS (common_flags()->suppressions is empty)
  # __asan_init calls SuppressionContext::Init(),  and SuppressionContext singleton is initialized to be empty
  # __lsan::InitCommonLsan() parses LSAN_OPTIONS (common_flags()->suppressions now points to LSan suppression file).
  # __lsan::InitCommonLsan() calls SuppressionContext::Init(), but it's already initialized, so we do nothing.

Now, this immediate problem can be "fixed" by moving the call to `InitializeSuppressions()` at the bottom, right before we print "AddressSanitizer Init done" string.
I think that we should probably do that and land your patch. But the situation is terrible - our initialization code is complicated and fragile. Currently ASan can be
(and is) combined with both LSan and UBSan, each of them have their own init logic, and can use XSAN_OPTIONS to setup and override common flags. Sigh.
I think we should put some thought into it and redesign that part soon.

http://reviews.llvm.org/D6280