summaryrefslogtreecommitdiff
path: root/lib/sanitizer_common/sanitizer_win_dll_thunk.h
AgeCommit message (Collapse)Author
2017-02-21[compiler-rt][asan] Fix incorrect macro preventing ICF with MSVCEtienne Bergeron
Summary: The DLL thunks are stubs added to an instrumented DLL to redirect ASAN API calls to the real ones in the main executable. These thunks must contain dummy code before __asan_init got called. Unfortunately, MSVC linker is doing ICF and is merging functions with the same body. In our case, this two ASAN thunks were incorrectly merged: ``` asan_interface.inc:16 INTERFACE_FUNCTION(__asan_before_dynamic_init) ``` ``` sanitizer_common_interface.inc:16 INTERFACE_FUNCTION(__sanitizer_verify_contiguous_container) ``` The same thunk got patched twice. After the second patching, calls to `__asan_before_dynamic_init` are redirected to `__sanitizer_verify_contiguous_container` and trigger a DCHECK on incorrect operands/ The problem was caused by the macro that is only using __LINE__ to prevent collapsing code. ``` #define INTERCEPT_SANITIZER_FUNCTION(name) extern "C" __declspec(noinline) void name() { volatile int prevent_icf = (__LINE__ << 8); (void)prevent_icf; ``` The current patch is adding __COUNTER__ which is safer than __LINE__. Also, to precent ICF (guarantee that code is different), we are using a unique attribute: - the name of the function Reviewers: rnk Reviewed By: rnk Subscribers: llvm-commits, kubamracek, chrisha, dberris Differential Revision: https://reviews.llvm.org/D30219 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295761 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-02[sanitizer] Intercept weak functions in dll_thunks.Marcos Pividori
In this diff, I update current implementation of the interception in dll_thunks to consider the special case of weak functions. First we check if the client has redefined the function in the main executable (for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The default implementation is always available because the static runtime is linked to the main executable. Differential Revision: https://reviews.llvm.org/D29155 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293952 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-02[sanitizer] Split dll_thunks into different sanitizers.Marcos Pividori
When the sanitizer is implemented as a static library and is included in the main executable, we need an auxiliary static library dll_thunk that will be linked to the dlls that have instrumentation, so they can refer to the runtime in the main executable. Basically, it uses interception to get a pointer the function in the main executable and override its function with that pointer. Before this diff, all of the implementation for dll_thunks was included in asan. In this diff I split it into different sanitizers, so we can use other sanitizers regardless of whether we include asan or not. All the sanitizers include a file sanitizer_win_dll_thunk.cc that register functions to be intercepted in the binary section: DLLTH When the dll including dll_thunk is initialized, it will execute __dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc, which will consider all the CB registered in the section DLLTH. So, all the functions registered will be intercepted, and redirected to the implementation in the main executable. All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan, ubsan and sanitizer coverage in the address sanitizer library. Differential Revision: https://reviews.llvm.org/D29154 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293951 91177308-0d34-0410-b5e6-96231b3b80d8