2012-04-05 06:12:04 +08:00
|
|
|
# Build for the AddressSanitizer runtime support library.
|
|
|
|
|
|
2012-06-20 18:18:43 +08:00
|
|
|
set(ASAN_SOURCES
|
2019-08-01 21:43:28 +08:00
|
|
|
asan_allocator.cpp
|
|
|
|
|
asan_activation.cpp
|
|
|
|
|
asan_debugging.cpp
|
|
|
|
|
asan_descriptions.cpp
|
|
|
|
|
asan_errors.cpp
|
|
|
|
|
asan_fake_stack.cpp
|
|
|
|
|
asan_flags.cpp
|
|
|
|
|
asan_fuchsia.cpp
|
|
|
|
|
asan_globals.cpp
|
|
|
|
|
asan_globals_win.cpp
|
|
|
|
|
asan_interceptors.cpp
|
|
|
|
|
asan_interceptors_memintrinsics.cpp
|
|
|
|
|
asan_linux.cpp
|
|
|
|
|
asan_mac.cpp
|
|
|
|
|
asan_malloc_linux.cpp
|
|
|
|
|
asan_malloc_mac.cpp
|
|
|
|
|
asan_malloc_win.cpp
|
|
|
|
|
asan_memory_profile.cpp
|
|
|
|
|
asan_poisoning.cpp
|
|
|
|
|
asan_posix.cpp
|
|
|
|
|
asan_premap_shadow.cpp
|
|
|
|
|
asan_report.cpp
|
|
|
|
|
asan_rtems.cpp
|
|
|
|
|
asan_rtl.cpp
|
|
|
|
|
asan_shadow_setup.cpp
|
|
|
|
|
asan_stack.cpp
|
|
|
|
|
asan_stats.cpp
|
|
|
|
|
asan_suppressions.cpp
|
|
|
|
|
asan_thread.cpp
|
|
|
|
|
asan_win.cpp
|
|
|
|
|
)
|
2012-04-05 06:12:04 +08:00
|
|
|
|
2019-02-28 06:23:51 +08:00
|
|
|
if (NOT WIN32 AND NOT APPLE)
|
2019-08-01 21:43:28 +08:00
|
|
|
list(APPEND ASAN_SOURCES
|
|
|
|
|
asan_interceptors_vfork.S
|
|
|
|
|
)
|
[hwasan, asan] Intercept vfork.
Summary:
Intercept vfork on arm, aarch64, i386 and x86_64.
Reviewers: pcc, vitalybuka
Subscribers: kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58533
llvm-svn: 355030
2019-02-28 05:11:50 +08:00
|
|
|
endif()
|
|
|
|
|
|
2014-05-13 02:39:22 +08:00
|
|
|
set(ASAN_CXX_SOURCES
|
2019-08-01 21:43:28 +08:00
|
|
|
asan_new_delete.cpp
|
|
|
|
|
)
|
2014-05-13 02:39:22 +08:00
|
|
|
|
2014-04-01 21:16:30 +08:00
|
|
|
set(ASAN_PREINIT_SOURCES
|
2019-08-01 21:43:28 +08:00
|
|
|
asan_preinit.cpp
|
|
|
|
|
)
|
2014-04-01 21:16:30 +08:00
|
|
|
|
2018-07-10 21:00:17 +08:00
|
|
|
SET(ASAN_HEADERS
|
|
|
|
|
asan_activation.h
|
|
|
|
|
asan_activation_flags.inc
|
|
|
|
|
asan_allocator.h
|
|
|
|
|
asan_descriptions.h
|
|
|
|
|
asan_errors.h
|
|
|
|
|
asan_fake_stack.h
|
|
|
|
|
asan_flags.h
|
|
|
|
|
asan_flags.inc
|
|
|
|
|
asan_init_version.h
|
|
|
|
|
asan_interceptors.h
|
|
|
|
|
asan_interceptors_memintrinsics.h
|
|
|
|
|
asan_interface.inc
|
|
|
|
|
asan_interface_internal.h
|
|
|
|
|
asan_internal.h
|
|
|
|
|
asan_lock.h
|
|
|
|
|
asan_malloc_local.h
|
|
|
|
|
asan_mapping.h
|
|
|
|
|
asan_mapping_myriad.h
|
|
|
|
|
asan_poisoning.h
|
|
|
|
|
asan_premap_shadow.h
|
|
|
|
|
asan_report.h
|
|
|
|
|
asan_scariness_score.h
|
|
|
|
|
asan_stack.h
|
|
|
|
|
asan_stats.h
|
|
|
|
|
asan_suppressions.h
|
2019-08-01 21:43:28 +08:00
|
|
|
asan_thread.h
|
|
|
|
|
)
|
2018-07-10 21:00:17 +08:00
|
|
|
|
2012-06-25 20:57:43 +08:00
|
|
|
include_directories(..)
|
|
|
|
|
|
2014-02-18 15:52:40 +08:00
|
|
|
set(ASAN_CFLAGS ${SANITIZER_COMMON_CFLAGS})
|
2017-11-13 22:02:27 +08:00
|
|
|
set(ASAN_COMMON_DEFINITIONS ${COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION})
|
2017-02-14 08:56:53 +08:00
|
|
|
|
2016-03-05 18:01:04 +08:00
|
|
|
append_rtti_flag(OFF ASAN_CFLAGS)
|
2012-09-05 17:00:03 +08:00
|
|
|
|
2017-07-28 11:39:38 +08:00
|
|
|
set(ASAN_DYNAMIC_LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS})
|
2015-05-06 04:13:39 +08:00
|
|
|
|
[sanitizer] Use -Wl,-z,global on Android for sanitizers except UBsan
Summary:
This essentially reverts r337010 since it breaks UBSan, which is used
for a few platform libraries. The "-z global" flag is now added for
Scudo as well. The only other sanitizer shared libraries are for asan
and hwasan, which have also been reinstated to use the global flag.
Reviewers: cryptoad, eugenis
Reviewed By: cryptoad
Subscribers: kubamracek, mgorny, delcypher, #sanitizers, nickdesaulniers, chh, kongyi, pirama, llvm-commits
Differential Revision: https://reviews.llvm.org/D52770
llvm-svn: 343599
2018-10-03 00:19:42 +08:00
|
|
|
if(ANDROID)
|
|
|
|
|
# Put most Sanitizer shared libraries in the global group. For more details, see
|
|
|
|
|
# android-changes-for-ndk-developers.md#changes-to-library-search-order
|
|
|
|
|
if (COMPILER_RT_HAS_Z_GLOBAL)
|
|
|
|
|
list(APPEND ASAN_DYNAMIC_LINK_FLAGS -Wl,-z,global)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2014-04-01 21:16:30 +08:00
|
|
|
set(ASAN_DYNAMIC_DEFINITIONS
|
|
|
|
|
${ASAN_COMMON_DEFINITIONS} ASAN_DYNAMIC=1)
|
2014-10-16 06:47:54 +08:00
|
|
|
append_list_if(WIN32 INTERCEPTION_DYNAMIC_CRT ASAN_DYNAMIC_DEFINITIONS)
|
2014-08-25 21:19:05 +08:00
|
|
|
|
2014-04-01 21:16:30 +08:00
|
|
|
set(ASAN_DYNAMIC_CFLAGS ${ASAN_CFLAGS})
|
2014-10-16 06:47:54 +08:00
|
|
|
append_list_if(COMPILER_RT_HAS_FTLS_MODEL_INITIAL_EXEC
|
2014-04-01 21:16:30 +08:00
|
|
|
-ftls-model=initial-exec ASAN_DYNAMIC_CFLAGS)
|
2016-06-30 05:54:50 +08:00
|
|
|
append_list_if(MSVC /DEBUG ASAN_DYNAMIC_LINK_FLAGS)
|
2014-04-01 21:16:30 +08:00
|
|
|
|
2019-02-16 16:34:26 +08:00
|
|
|
set(ASAN_DYNAMIC_LIBS ${SANITIZER_CXX_ABI_LIBRARIES} ${SANITIZER_COMMON_LINK_LIBS})
|
2017-07-28 11:39:38 +08:00
|
|
|
|
2014-10-16 06:47:54 +08:00
|
|
|
append_list_if(COMPILER_RT_HAS_LIBDL dl ASAN_DYNAMIC_LIBS)
|
2015-05-30 06:31:28 +08:00
|
|
|
append_list_if(COMPILER_RT_HAS_LIBRT rt ASAN_DYNAMIC_LIBS)
|
2014-10-16 06:47:54 +08:00
|
|
|
append_list_if(COMPILER_RT_HAS_LIBM m ASAN_DYNAMIC_LIBS)
|
|
|
|
|
append_list_if(COMPILER_RT_HAS_LIBPTHREAD pthread ASAN_DYNAMIC_LIBS)
|
2015-07-25 03:00:16 +08:00
|
|
|
append_list_if(COMPILER_RT_HAS_LIBLOG log ASAN_DYNAMIC_LIBS)
|
2018-09-26 14:53:01 +08:00
|
|
|
append_list_if(MINGW "${MINGW_LIBRARIES}" ASAN_DYNAMIC_LIBS)
|
2014-09-29 21:18:55 +08:00
|
|
|
|
2013-09-16 23:50:53 +08:00
|
|
|
# Compile ASan sources into an object library.
|
2015-08-27 02:33:51 +08:00
|
|
|
|
2016-06-21 22:32:52 +08:00
|
|
|
add_compiler_rt_object_libraries(RTAsan_dynamic
|
2015-08-27 02:33:51 +08:00
|
|
|
OS ${SANITIZER_COMMON_SUPPORTED_OS}
|
|
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
|
|
|
|
SOURCES ${ASAN_SOURCES} ${ASAN_CXX_SOURCES}
|
2018-07-10 21:00:17 +08:00
|
|
|
ADDITIONAL_HEADERS ${ASAN_HEADERS}
|
2015-08-27 02:33:51 +08:00
|
|
|
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_DYNAMIC_DEFINITIONS})
|
2015-08-27 02:33:51 +08:00
|
|
|
|
|
|
|
|
if(NOT APPLE)
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_object_libraries(RTAsan
|
2015-06-19 11:39:24 +08:00
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
2018-07-10 21:00:17 +08:00
|
|
|
SOURCES ${ASAN_SOURCES}
|
|
|
|
|
ADDITIONAL_HEADERS ${ASAN_HEADERS}
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_object_libraries(RTAsan_cxx
|
2015-06-19 11:39:24 +08:00
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
2018-07-10 21:00:17 +08:00
|
|
|
SOURCES ${ASAN_CXX_SOURCES}
|
|
|
|
|
ADDITIONAL_HEADERS ${ASAN_HEADERS}
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_object_libraries(RTAsan_preinit
|
2015-06-19 11:39:24 +08:00
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
2018-07-10 21:00:17 +08:00
|
|
|
SOURCES ${ASAN_PREINIT_SOURCES}
|
|
|
|
|
ADDITIONAL_HEADERS ${ASAN_HEADERS}
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
2015-05-28 06:38:01 +08:00
|
|
|
|
2019-08-01 21:43:28 +08:00
|
|
|
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp "")
|
2015-06-11 07:55:07 +08:00
|
|
|
add_compiler_rt_object_libraries(RTAsan_dynamic_version_script_dummy
|
2015-06-19 11:39:24 +08:00
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
2019-08-01 21:43:28 +08:00
|
|
|
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp
|
2015-06-11 07:55:07 +08:00
|
|
|
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_DYNAMIC_DEFINITIONS})
|
2013-09-16 23:50:53 +08:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Build ASan runtimes shipped with Clang.
|
2016-08-27 04:52:22 +08:00
|
|
|
add_compiler_rt_component(asan)
|
2016-07-12 07:09:33 +08:00
|
|
|
|
2012-08-10 22:45:52 +08:00
|
|
|
if(APPLE)
|
2017-01-10 12:33:04 +08:00
|
|
|
add_weak_symbols("asan" WEAK_SYMBOL_LINK_FLAGS)
|
2017-02-14 08:56:53 +08:00
|
|
|
add_weak_symbols("lsan" WEAK_SYMBOL_LINK_FLAGS)
|
2017-01-10 12:33:04 +08:00
|
|
|
add_weak_symbols("ubsan" WEAK_SYMBOL_LINK_FLAGS)
|
|
|
|
|
add_weak_symbols("sanitizer_common" WEAK_SYMBOL_LINK_FLAGS)
|
2018-08-30 13:55:27 +08:00
|
|
|
add_weak_symbols("xray" WEAK_SYMBOL_LINK_FLAGS)
|
2017-01-09 11:51:42 +08:00
|
|
|
|
2015-08-27 02:33:51 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan
|
|
|
|
|
SHARED
|
|
|
|
|
OS ${SANITIZER_COMMON_SUPPORTED_OS}
|
|
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
|
|
|
|
OBJECT_LIBS RTAsan_dynamic
|
|
|
|
|
RTInterception
|
|
|
|
|
RTSanitizerCommon
|
2015-08-28 06:23:27 +08:00
|
|
|
RTSanitizerCommonLibc
|
[sanitizer] Split coverage into separate RT in sanitizer_common
Summary:
`sanitizer_common`'s coverage support is fairly well separated, and libcdep by
default. Several sanitizers don't make use of coverage, and as far as I can
tell do no benefit from the extra dependencies pulled in by the coverage public
interface functions.
The following sanitizers call `InitializeCoverage` explicitely: MSan, ASan,
LSan, HWAsan, UBSan. On top of this, any sanitizer bundling RTUBSan should
add the coverage RT as well: ASan, Scudo, UBSan, CFI (diag), TSan, MSan, HWAsan.
So in the end the following have no need: DFSan, ESan, CFI, SafeStack (nolibc
anyway), XRay, and the upcoming Scudo minimal runtime.
I tested this with all the sanitizers check-* with gcc & clang, and in
standalone on Linux & Android, and there was no issue. I couldn't test this on
Mac, Fuchsia, BSDs, & Windows for lack of an environment, so adding a bunch of
people for additional scrunity. I couldn't test HWAsan either.
Reviewers: eugenis, vitalybuka, alekseyshl, flowerhack, kubamracek, dberris, rnk, krytarowski
Reviewed By: vitalybuka, alekseyshl, flowerhack, dberris
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44701
llvm-svn: 328204
2018-03-22 23:04:31 +08:00
|
|
|
RTSanitizerCommonCoverage
|
[sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommon
Summary:
Host symbolizer & stacktraces related code in their own RT:
`RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer &
stacktraces specific code that used to live in common files is moved to a new
file `sanitizer_symbolizer_report.cc` as is.
The purpose of this is the enforce a separation between code that relies on
symbolization and code that doesn't. This saves the inclusion of spurious code
due to the interface functions with default visibility, and the extra data
associated.
The following sanitizers makefiles were modified & tested locally:
- dfsan: doesn't require the new symbolizer RT
- esan: requires it
- hwasan: requires it
- lsan: requires it
- msan: requires it
- safestack: doesn't require it
- xray: doesn't require it
- tsan: requires it
- ubsan: requires it
- ubsan_minimal: doesn't require it
- scudo: requires it (but not for Fuchsia that has a minimal runtime)
This was tested locally on Linux, Android, Fuchsia.
Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr
Reviewed By: alekseyshl, vitalybuka
Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45457
llvm-svn: 330131
2018-04-17 00:32:19 +08:00
|
|
|
RTSanitizerCommonSymbolizer
|
2015-08-27 02:33:51 +08:00
|
|
|
RTLSanCommon
|
|
|
|
|
RTUbsan
|
|
|
|
|
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
|
2017-01-10 12:33:04 +08:00
|
|
|
LINK_FLAGS ${WEAK_SYMBOL_LINK_FLAGS}
|
2015-08-27 02:33:51 +08:00
|
|
|
DEFS ${ASAN_DYNAMIC_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2012-08-10 22:45:52 +08:00
|
|
|
else()
|
2013-09-16 23:50:53 +08:00
|
|
|
# Build separate libraries for each target.
|
2016-06-21 22:32:52 +08:00
|
|
|
|
2016-07-11 05:06:06 +08:00
|
|
|
set(ASAN_COMMON_RUNTIME_OBJECT_LIBS
|
|
|
|
|
RTInterception
|
|
|
|
|
RTSanitizerCommon
|
|
|
|
|
RTSanitizerCommonLibc
|
[sanitizer] Split coverage into separate RT in sanitizer_common
Summary:
`sanitizer_common`'s coverage support is fairly well separated, and libcdep by
default. Several sanitizers don't make use of coverage, and as far as I can
tell do no benefit from the extra dependencies pulled in by the coverage public
interface functions.
The following sanitizers call `InitializeCoverage` explicitely: MSan, ASan,
LSan, HWAsan, UBSan. On top of this, any sanitizer bundling RTUBSan should
add the coverage RT as well: ASan, Scudo, UBSan, CFI (diag), TSan, MSan, HWAsan.
So in the end the following have no need: DFSan, ESan, CFI, SafeStack (nolibc
anyway), XRay, and the upcoming Scudo minimal runtime.
I tested this with all the sanitizers check-* with gcc & clang, and in
standalone on Linux & Android, and there was no issue. I couldn't test this on
Mac, Fuchsia, BSDs, & Windows for lack of an environment, so adding a bunch of
people for additional scrunity. I couldn't test HWAsan either.
Reviewers: eugenis, vitalybuka, alekseyshl, flowerhack, kubamracek, dberris, rnk, krytarowski
Reviewed By: vitalybuka, alekseyshl, flowerhack, dberris
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44701
llvm-svn: 328204
2018-03-22 23:04:31 +08:00
|
|
|
RTSanitizerCommonCoverage
|
[sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommon
Summary:
Host symbolizer & stacktraces related code in their own RT:
`RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer &
stacktraces specific code that used to live in common files is moved to a new
file `sanitizer_symbolizer_report.cc` as is.
The purpose of this is the enforce a separation between code that relies on
symbolization and code that doesn't. This saves the inclusion of spurious code
due to the interface functions with default visibility, and the extra data
associated.
The following sanitizers makefiles were modified & tested locally:
- dfsan: doesn't require the new symbolizer RT
- esan: requires it
- hwasan: requires it
- lsan: requires it
- msan: requires it
- safestack: doesn't require it
- xray: doesn't require it
- tsan: requires it
- ubsan: requires it
- ubsan_minimal: doesn't require it
- scudo: requires it (but not for Fuchsia that has a minimal runtime)
This was tested locally on Linux, Android, Fuchsia.
Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr
Reviewed By: alekseyshl, vitalybuka
Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45457
llvm-svn: 330131
2018-04-17 00:32:19 +08:00
|
|
|
RTSanitizerCommonSymbolizer
|
2016-07-11 05:06:06 +08:00
|
|
|
RTLSanCommon
|
|
|
|
|
RTUbsan)
|
2013-08-27 09:24:01 +08:00
|
|
|
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan
|
|
|
|
|
STATIC
|
|
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
|
|
|
|
OBJECT_LIBS RTAsan_preinit
|
|
|
|
|
RTAsan
|
|
|
|
|
${ASAN_COMMON_RUNTIME_OBJECT_LIBS}
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
|
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2014-04-01 21:16:30 +08:00
|
|
|
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan_cxx
|
|
|
|
|
STATIC
|
|
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
|
|
|
|
OBJECT_LIBS RTAsan_cxx
|
|
|
|
|
RTUbsan_cxx
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
|
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2014-05-13 02:39:22 +08:00
|
|
|
|
2016-07-11 05:06:06 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan-preinit
|
|
|
|
|
STATIC
|
|
|
|
|
ARCHS ${ASAN_SUPPORTED_ARCH}
|
|
|
|
|
OBJECT_LIBS RTAsan_preinit
|
|
|
|
|
CFLAGS ${ASAN_CFLAGS}
|
|
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2014-12-18 07:14:01 +08:00
|
|
|
|
2015-08-27 02:33:51 +08:00
|
|
|
foreach(arch ${ASAN_SUPPORTED_ARCH})
|
2020-07-30 16:27:36 +08:00
|
|
|
if (COMPILER_RT_HAS_VERSION_SCRIPT)
|
2015-05-06 06:51:35 +08:00
|
|
|
add_sanitizer_rt_version_list(clang_rt.asan-dynamic-${arch}
|
2015-06-19 11:39:24 +08:00
|
|
|
LIBS clang_rt.asan-${arch} clang_rt.asan_cxx-${arch}
|
2015-05-06 06:51:35 +08:00
|
|
|
EXTRA asan.syms.extra)
|
2015-05-06 07:13:50 +08:00
|
|
|
set(VERSION_SCRIPT_FLAG
|
2015-05-06 06:51:35 +08:00
|
|
|
-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/clang_rt.asan-dynamic-${arch}.vers)
|
[Sanitizers, CMake] Basic sanitizer Solaris support (PR 33274)
Summary:
This patch, on top of https://reviews.llvm.org/D40898, contains the build system
changes necessary to enable the Solaris/x86 sanitizer port.
The only issue of note is the libclang_rt.sancov_{begin, end} libraries: clang relies on the
linker automatically defining __start_SECNAME and __stop_SECNAME labels for
sections whose names are valid C identifiers. This is a GNU ld extension not present
in the ELF gABI, also implemented by gold and lld, but not by Solaris ld. To work around
this, I automatically link the sancov_{begin,end} libraries into every executable for now.
There seems to be now way to build individual startup objects like crtbegin.o/crtend.o,
so I've followed the lead of libclang_rt.asan-preinit which also contains just a single
object.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40899
llvm-svn: 321373
2017-12-23 02:04:20 +08:00
|
|
|
# The Solaris 11.4 linker supports a subset of GNU ld version scripts,
|
|
|
|
|
# but requires a special option to enable it.
|
2020-10-13 18:02:30 +08:00
|
|
|
if (COMPILER_RT_HAS_GNU_VERSION_SCRIPT_COMPAT)
|
[Sanitizers, CMake] Basic sanitizer Solaris support (PR 33274)
Summary:
This patch, on top of https://reviews.llvm.org/D40898, contains the build system
changes necessary to enable the Solaris/x86 sanitizer port.
The only issue of note is the libclang_rt.sancov_{begin, end} libraries: clang relies on the
linker automatically defining __start_SECNAME and __stop_SECNAME labels for
sections whose names are valid C identifiers. This is a GNU ld extension not present
in the ELF gABI, also implemented by gold and lld, but not by Solaris ld. To work around
this, I automatically link the sancov_{begin,end} libraries into every executable for now.
There seems to be now way to build individual startup objects like crtbegin.o/crtend.o,
so I've followed the lead of libclang_rt.asan-preinit which also contains just a single
object.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40899
llvm-svn: 321373
2017-12-23 02:04:20 +08:00
|
|
|
list(APPEND VERSION_SCRIPT_FLAG -Wl,-z,gnu-version-script-compat)
|
|
|
|
|
endif()
|
2017-08-22 06:31:31 +08:00
|
|
|
set_property(SOURCE
|
2019-08-01 21:43:28 +08:00
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp
|
2017-08-22 06:31:31 +08:00
|
|
|
APPEND PROPERTY
|
2016-06-21 22:32:52 +08:00
|
|
|
OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang_rt.asan-dynamic-${arch}.vers)
|
2015-05-06 07:13:50 +08:00
|
|
|
else()
|
|
|
|
|
set(VERSION_SCRIPT_FLAG)
|
2015-05-06 06:51:35 +08:00
|
|
|
endif()
|
|
|
|
|
|
[sanitizer] Use interception to access to strong definitions in the executable.
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
2017-02-03 07:02:11 +08:00
|
|
|
set(ASAN_DYNAMIC_WEAK_INTERCEPTION)
|
2018-09-26 14:53:01 +08:00
|
|
|
if (WIN32)
|
[sanitizer] Use interception to access to strong definitions in the executable.
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
2017-02-03 07:02:11 +08:00
|
|
|
add_compiler_rt_object_libraries(AsanWeakInterception
|
|
|
|
|
${SANITIZER_COMMON_SUPPORTED_OS}
|
2017-02-09 04:43:39 +08:00
|
|
|
ARCHS ${arch}
|
2019-08-01 21:43:28 +08:00
|
|
|
SOURCES asan_win_weak_interception.cpp
|
[sanitizer] Use interception to access to strong definitions in the executable.
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
2017-02-03 07:02:11 +08:00
|
|
|
CFLAGS ${ASAN_CFLAGS} -DSANITIZER_DYNAMIC
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
[sanitizer] Use interception to access to strong definitions in the executable.
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
2017-02-03 07:02:11 +08:00
|
|
|
set(ASAN_DYNAMIC_WEAK_INTERCEPTION
|
|
|
|
|
AsanWeakInterception
|
|
|
|
|
UbsanWeakInterception
|
|
|
|
|
SancovWeakInterception
|
|
|
|
|
SanitizerCommonWeakInterception)
|
|
|
|
|
endif()
|
|
|
|
|
|
2015-08-26 03:53:09 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan
|
|
|
|
|
SHARED
|
|
|
|
|
ARCHS ${arch}
|
2015-08-27 02:33:51 +08:00
|
|
|
OBJECT_LIBS ${ASAN_COMMON_RUNTIME_OBJECT_LIBS}
|
|
|
|
|
RTAsan_dynamic
|
2017-08-22 06:31:31 +08:00
|
|
|
# The only purpose of RTAsan_dynamic_version_script_dummy is to
|
|
|
|
|
# carry a dependency of the shared runtime on the version script.
|
|
|
|
|
# Replacing it with a straightforward
|
2015-05-28 06:38:01 +08:00
|
|
|
# add_dependencies(clang_rt.asan-dynamic-${arch} clang_rt.asan-dynamic-${arch}-version-list)
|
2017-08-22 06:31:31 +08:00
|
|
|
# generates an order-only dependency in ninja.
|
2015-08-27 02:33:51 +08:00
|
|
|
RTAsan_dynamic_version_script_dummy
|
|
|
|
|
RTUbsan_cxx
|
[sanitizer] Use interception to access to strong definitions in the executable.
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
2017-02-03 07:02:11 +08:00
|
|
|
${ASAN_DYNAMIC_WEAK_INTERCEPTION}
|
2014-12-18 07:14:01 +08:00
|
|
|
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
|
2017-01-10 12:33:04 +08:00
|
|
|
LINK_FLAGS ${ASAN_DYNAMIC_LINK_FLAGS}
|
2015-05-06 07:13:50 +08:00
|
|
|
${VERSION_SCRIPT_FLAG}
|
2015-08-26 04:00:35 +08:00
|
|
|
LINK_LIBS ${ASAN_DYNAMIC_LIBS}
|
2015-08-26 03:53:09 +08:00
|
|
|
DEFS ${ASAN_DYNAMIC_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2014-04-01 21:16:30 +08:00
|
|
|
|
2018-05-10 05:24:06 +08:00
|
|
|
if (SANITIZER_USE_SYMBOLS AND NOT ${arch} STREQUAL "i386")
|
2015-08-28 04:07:54 +08:00
|
|
|
add_sanitizer_rt_symbols(clang_rt.asan_cxx
|
|
|
|
|
ARCHS ${arch})
|
2014-05-13 02:39:22 +08:00
|
|
|
add_dependencies(asan clang_rt.asan_cxx-${arch}-symbols)
|
2015-08-28 04:07:54 +08:00
|
|
|
add_sanitizer_rt_symbols(clang_rt.asan
|
2016-07-11 05:06:06 +08:00
|
|
|
ARCHS ${arch}
|
2015-08-27 07:12:25 +08:00
|
|
|
EXTRA asan.syms.extra)
|
2014-02-14 22:45:13 +08:00
|
|
|
add_dependencies(asan clang_rt.asan-${arch}-symbols)
|
2013-08-28 16:07:04 +08:00
|
|
|
endif()
|
2013-08-27 09:24:01 +08:00
|
|
|
|
|
|
|
|
if (WIN32)
|
[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
|
|
|
add_compiler_rt_object_libraries(AsanDllThunk
|
|
|
|
|
${SANITIZER_COMMON_SUPPORTED_OS}
|
2017-02-09 04:43:39 +08:00
|
|
|
ARCHS ${arch}
|
2019-08-01 21:43:28 +08:00
|
|
|
SOURCES asan_globals_win.cpp
|
|
|
|
|
asan_win_dll_thunk.cpp
|
[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
|
|
|
CFLAGS ${ASAN_CFLAGS} -DSANITIZER_DLL_THUNK
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
[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
|
|
|
|
2015-08-26 03:53:09 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan_dll_thunk
|
|
|
|
|
STATIC
|
|
|
|
|
ARCHS ${arch}
|
[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
|
|
|
OBJECT_LIBS AsanDllThunk
|
|
|
|
|
UbsanDllThunk
|
|
|
|
|
SancovDllThunk
|
|
|
|
|
SanitizerCommonDllThunk
|
|
|
|
|
SOURCES $<TARGET_OBJECTS:RTInterception.${arch}>
|
2015-08-26 03:53:09 +08:00
|
|
|
PARENT_TARGET asan)
|
2016-09-08 05:03:22 +08:00
|
|
|
|
[sanitizer] Add dynamic_runtime_thunk for different sanitizers.
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
2017-02-03 07:01:41 +08:00
|
|
|
set(DYNAMIC_RUNTIME_THUNK_CFLAGS "-DSANITIZER_DYNAMIC_RUNTIME_THUNK")
|
2016-09-08 05:03:22 +08:00
|
|
|
if(MSVC)
|
|
|
|
|
list(APPEND DYNAMIC_RUNTIME_THUNK_CFLAGS "-Zl")
|
|
|
|
|
elseif(CMAKE_C_COMPILER_ID MATCHES Clang)
|
|
|
|
|
list(APPEND DYNAMIC_RUNTIME_THUNK_CFLAGS "-nodefaultlibs")
|
|
|
|
|
endif()
|
|
|
|
|
|
[sanitizer] Add dynamic_runtime_thunk for different sanitizers.
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
2017-02-03 07:01:41 +08:00
|
|
|
add_compiler_rt_object_libraries(AsanDynamicRuntimeThunk
|
|
|
|
|
${SANITIZER_COMMON_SUPPORTED_OS}
|
2017-02-09 04:43:39 +08:00
|
|
|
ARCHS ${arch}
|
2019-08-01 21:43:28 +08:00
|
|
|
SOURCES asan_globals_win.cpp
|
|
|
|
|
asan_win_dynamic_runtime_thunk.cpp
|
[sanitizer] Add dynamic_runtime_thunk for different sanitizers.
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
2017-02-03 07:01:41 +08:00
|
|
|
CFLAGS ${ASAN_CFLAGS} ${DYNAMIC_RUNTIME_THUNK_CFLAGS}
|
2020-10-31 07:16:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS})
|
[sanitizer] Add dynamic_runtime_thunk for different sanitizers.
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
2017-02-03 07:01:41 +08:00
|
|
|
|
2015-08-26 03:53:09 +08:00
|
|
|
add_compiler_rt_runtime(clang_rt.asan_dynamic_runtime_thunk
|
2014-09-12 21:21:02 +08:00
|
|
|
STATIC
|
2015-08-26 03:53:09 +08:00
|
|
|
ARCHS ${arch}
|
[sanitizer] Add dynamic_runtime_thunk for different sanitizers.
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
2017-02-03 07:01:41 +08:00
|
|
|
OBJECT_LIBS AsanDynamicRuntimeThunk
|
|
|
|
|
UbsanDynamicRuntimeThunk
|
|
|
|
|
SancovDynamicRuntimeThunk
|
|
|
|
|
SanitizerCommonDynamicRuntimeThunk
|
2016-09-08 05:03:22 +08:00
|
|
|
CFLAGS ${ASAN_CFLAGS} ${DYNAMIC_RUNTIME_THUNK_CFLAGS}
|
2015-08-26 03:53:09 +08:00
|
|
|
DEFS ${ASAN_COMMON_DEFINITIONS}
|
|
|
|
|
PARENT_TARGET asan)
|
2013-08-27 09:24:01 +08:00
|
|
|
endif()
|
2013-01-19 00:51:07 +08:00
|
|
|
endforeach()
|
2012-04-05 06:12:04 +08:00
|
|
|
endif()
|
2012-06-25 20:57:43 +08:00
|
|
|
|
2016-02-24 05:50:39 +08:00
|
|
|
add_compiler_rt_resource_file(asan_blacklist asan_blacklist.txt asan)
|
2013-11-14 20:24:12 +08:00
|
|
|
|
2014-02-27 16:41:40 +08:00
|
|
|
add_subdirectory(scripts)
|
|
|
|
|
|
2014-02-19 19:18:47 +08:00
|
|
|
if(COMPILER_RT_INCLUDE_TESTS)
|
2012-06-25 20:57:43 +08:00
|
|
|
add_subdirectory(tests)
|
|
|
|
|
endif()
|