When considering MD, asan is implemented as an external dll: clang-rt_asan_dynamic-arch.dll
Also, a static library clang-rt_asan_dynamic_runtime_thunk-arch.lib, which provides some functionalities, is statically linked with both, instrumented dlls and executables,
As I mentioned in the previous revision: https://reviews.llvm.org/D28596 , for asan dll on windows, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(), which export the default implementation with __dll suffix. For example: for __sanitizer_cov_trace_cmp , its default implementation is exported as: __sanitizer_cov_trace_cmp__dll.
So, in this diff I update clang-rt_asan_dynamic_runtime_thunk-arch.lib to include weak aliases to the imported implementation from asan dll, using the macro WIN_WEAK_IMPORT_DEF() like:
WIN_WEAK_IMPORT_DEF(__sanitizer_cov_trace_cmp); WIN_WEAK_IMPORT_DEF(__sanitizer_cov_trace_cmp1); ....
Which will be expanded to "weak aliases":
__sanitizer_cov_trace_cmp = __sanitizer_cov_trace_cmp__dll __sanitizer_cov_trace_cmp1 = __sanitizer_cov_trace_cmp1__dll .....
So, by default, all users's programs that include calls to weak functions like __sanitizer_cov_trace_cmp, will be redirected to the implementation in asan dll, when linking to clang-rt_asan_dynamic_runtime_thunk-arch.lib.
After this diff, we are able to compile code with MD and sanitizer coverage instrumentation. When the instrumented object files are linked with clang-rt_asan_dynamic_runtime_thunk-arch.lib all the symbols will be resolved to the implementation imported from asan dll.
Also, I need to remove SANITIZER_INTERFACE_ATTRIBUTE from __asan_shadow_memory_dynamic_address and __asan_option_detect_stack_use_after_return, because we are not exporting that symbols, since we redefine them in asan_win_dynamic_runtime_thunk.cc. Otherwise, the compiler fails because the declaration included from the header includes SANITIZER_INTERFACE_ATTRIBUTE (which expands to dllimport), and the definition in asan_win_dynamic_runtime_thunk.cc doesn't include SANITIZER_INTERFACE_ATTRIBUTE.