These "dynamic_runtime_thunk" object files exist to create a weak alias
from 'foo' to 'foo_dll' for all weak sanitizer runtime symbols. The weak
aliases are implemented as /alternatename linker options in the
.drective section, so they are not actually in the symbol table. In
order to force the Visual C++ linker to load the object, even with
-wholearchive:, we have to provide at least one external symbol. Once we
do that, it will read the .drective sections and see the weak aliases.
Fixes PR42074
llvm-svn: 362970
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
Reid Kleckner