summaryrefslogtreecommitdiff
path: root/lib/asan/asan_globals_win.cc
AgeCommit message (Collapse)Author
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
2016-11-23[asan/win] Check assumptions about the incremental linker moreReid Kleckner
Remove a needless cast as well. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287785 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-23[asan/win] Fix incremental linking vs. global registrationReid Kleckner
The MSVC incremental linker pads every global out to 256 bytes in case it changes size after an incremental link. So, skip over null entries in the DSO-wide asan globals array. This only works if the global padding size is divisible by the size of the asan global object, so add some defensive CHECKs. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287780 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-17[asan] Create a .ASAN$G(A-Z) section for global registrationReid Kleckner
Summary: The expectation is that new instrumented code will add global variable metadata to the .ASAN$GL section, and we will use this new code to iterate over it. This technique seems to break when using incremental linking, which seems to align every global to a 256 byte boundary. Presumably this is so that it can incrementally cope with global changing size. Clang already passes -incremental:no as a linker flag when you invoke it to do the link step. The two tests added for this feature will fail until the LLVM instrumentation change in D26770 lands, so they are marked XFAIL for now. Reviewers: pcc, kcc, mehdi_amini, kubabrecka Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D26771 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287246 91177308-0d34-0410-b5e6-96231b3b80d8