llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_win_defs.h

154 lines
6.5 KiB
C
Raw Normal View History

//===-- sanitizer_win_defs.h ------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// Common definitions for Windows-specific code.
//
//===----------------------------------------------------------------------===//
#ifndef SANITIZER_WIN_DEFS_H
#define SANITIZER_WIN_DEFS_H
#include "sanitizer_platform.h"
#if SANITIZER_WINDOWS
#ifndef WINAPI
[sanitizer] Split dll_thunks into different sanitizers. 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 llvm-svn: 293951
2017-02-03 07:01:28 +08:00
#ifdef _M_IX86
#define WINAPI __stdcall
#else
#define WINAPI
#endif
#endif
[sanitizer] Split dll_thunks into different sanitizers. 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 llvm-svn: 293951
2017-02-03 07:01:28 +08:00
#if defined(_WIN64)
#define WIN_SYM_PREFIX
#else
#define WIN_SYM_PREFIX "_"
#endif
// Intermediate macro to ensure the parameter is expanded before stringified.
#define STRINGIFY_(A) #A
#define STRINGIFY(A) STRINGIFY_(A)
// ----------------- A workaround for the absence of weak symbols --------------
// We don't have a direct equivalent of weak symbols when using MSVC, but we can
// use the /alternatename directive to tell the linker to default a specific
// symbol to a specific value.
// Take into account that this is a pragma directive for the linker, so it will
// be ignored by the compiler and the function will be marked as UNDEF in the
// symbol table of the resulting object file. The linker won't find the default
// implementation until it links with that object file.
// So, suppose we provide a default implementation "fundef" for "fun", and this
// is compiled into the object file "test.obj" including the pragma directive.
// If we have some code with references to "fun" and we link that code with
// "test.obj", it will work because the linker always link object files.
// But, if "test.obj" is included in a static library, like "test.lib", then the
// liker will only link to "test.obj" if necessary. If we only included the
// definition of "fun", it won't link to "test.obj" (from test.lib) because
// "fun" appears as UNDEF, so it doesn't resolve the symbol "fun", and will
// result in a link error (the linker doesn't find the pragma directive).
// So, a workaround is to force linkage with the modules that include weak
// definitions, with the following macro: WIN_FORCE_LINK()
#define WIN_WEAK_ALIAS(Name, Default) \
__pragma(comment(linker, "/alternatename:" WIN_SYM_PREFIX STRINGIFY(Name) "="\
WIN_SYM_PREFIX STRINGIFY(Default)))
#define WIN_FORCE_LINK(Name) \
__pragma(comment(linker, "/include:" WIN_SYM_PREFIX STRINGIFY(Name)))
#define WIN_EXPORT(ExportedName, Name) \
__pragma(comment(linker, "/export:" WIN_SYM_PREFIX STRINGIFY(ExportedName) \
"=" WIN_SYM_PREFIX STRINGIFY(Name)))
// We cannot define weak functions on Windows, but we can use WIN_WEAK_ALIAS()
// which defines an alias to a default implementation, and only works when
// linking statically.
// So, to define a weak function "fun", we define a default implementation with
// a different name "fun__def" and we create a "weak alias" fun = fun__def.
// Then, users can override it just defining "fun".
// We impose "extern "C"" because otherwise WIN_WEAK_ALIAS() will fail because
// of name mangling.
// Dummy name for default implementation of weak function.
# define WEAK_DEFAULT_NAME(Name) Name##__def
// Name for exported implementation of weak function.
# define WEAK_EXPORT_NAME(Name) Name##__dll
// Use this macro when you need to define and export a weak function from a
// library. For example:
// WIN_WEAK_EXPORT_DEF(bool, compare, int a, int b) { return a > b; }
# define WIN_WEAK_EXPORT_DEF(ReturnType, Name, ...) \
WIN_WEAK_ALIAS(Name, WEAK_DEFAULT_NAME(Name)) \
WIN_EXPORT(WEAK_EXPORT_NAME(Name), Name) \
extern "C" ReturnType Name(__VA_ARGS__); \
extern "C" ReturnType WEAK_DEFAULT_NAME(Name)(__VA_ARGS__)
// Use this macro when you need to import a weak function from a library. It
// defines a weak alias to the imported function from the dll. For example:
// WIN_WEAK_IMPORT_DEF(compare)
# define WIN_WEAK_IMPORT_DEF(Name) \
WIN_WEAK_ALIAS(Name, WEAK_EXPORT_NAME(Name))
// So, for Windows we provide something similar to weak symbols in Linux, with
// some differences:
// + A default implementation must always be provided.
//
// + When linking statically it works quite similarly. For example:
//
// // libExample.cc
// WIN_WEAK_EXPORT_DEF(bool, compare, int a, int b) { return a > b; }
//
// // client.cc
// // We can use the default implementation from the library:
// compare(1, 2);
// // Or we can override it:
// extern "C" bool compare (int a, int b) { return a >= b; }
//
// And it will work fine. If we don't override the function, we need to ensure
// that the linker includes the object file with the default implementation.
// We can do so with the linker option "-wholearchive:".
//
// + When linking dynamically with a library (dll), weak functions are exported
// with "__dll" suffix. Clients can use the macro WIN_WEAK_IMPORT_DEF(fun)
// which defines a "weak alias" fun = fun__dll.
//
// // libExample.cc
// WIN_WEAK_EXPORT_DEF(bool, compare, int a, int b) { return a > b; }
//
// // client.cc
// WIN_WEAK_IMPORT_DEF(compare)
// // We can use the default implementation from the library:
// compare(1, 2);
// // Or we can override it:
// extern "C" bool compare (int a, int b) { return a >= b; }
//
// But if we override the function, the dlls don't have access to it (which
// is different in linux). If that is desired, the strong definition must be
// exported and interception can be used from the rest of the dlls.
//
// // libExample.cc
// WIN_WEAK_EXPORT_DEF(bool, compare, int a, int b) { return a > b; }
// // When initialized, check if the main executable defined "compare".
// int libExample_init() {
// uptr fnptr = __interception::InternalGetProcAddress(
// (void *)GetModuleHandleA(0), "compare");
// if (fnptr && !__interception::OverrideFunction((uptr)compare, fnptr, 0))
// abort();
// return 0;
// }
//
// // client.cc
// WIN_WEAK_IMPORT_DEF(compare)
// // We override and export compare:
// extern "C" __declspec(dllexport) bool compare (int a, int b) {
// return a >= b;
// }
//
#endif // SANITIZER_WINDOWS
#endif // SANITIZER_WIN_DEFS_H