maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/lib/hwasan/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

185 lines
5.7 KiB
CMake
Raw Normal View History

Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
include_directories(..)
# Runtime library sources and build flags.
set(HWASAN_RTL_SOURCES
hwasan: Rename source files from cc to cpp As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
2019-02-27 23:44:03 +08:00
hwasan.cpp
hwasan_allocator.cpp
hwasan_dynamic_shadow.cpp
hwasan: Untag unwound stack frames by wrapping personality functions. One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
2019-08-23 09:28:44 +08:00
hwasan_exceptions.cpp
hwasan: Rename source files from cc to cpp As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
2019-02-27 23:44:03 +08:00
hwasan_interceptors.cpp
[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
hwasan_interceptors_vfork.S
hwasan: Rename source files from cc to cpp As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
2019-02-27 23:44:03 +08:00
hwasan_linux.cpp
hwasan_memintrinsics.cpp
hwasan_poisoning.cpp
hwasan_report.cpp
[HWASan] Save + print registers when tag mismatch occurs in AArch64. Summary: This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance. In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable. The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format: Registers where the failure occurred (pc 0x0055555561b4): x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025 x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001 x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000 x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000 x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078 x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4 ... and prints after the dump of memory tags around the buggy address. Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging. Reviewers: pcc, eugenis Reviewed By: pcc, eugenis Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58857 llvm-svn: 355738
2019-03-09 05:22:35 +08:00
hwasan_tag_mismatch_aarch64.S
hwasan: Rename source files from cc to cpp As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
2019-02-27 23:44:03 +08:00
hwasan_thread.cpp
hwasan_thread_list.cpp
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
)
set(HWASAN_RTL_CXX_SOURCES
hwasan: Rename source files from cc to cpp As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
2019-02-27 23:44:03 +08:00
hwasan_new_delete.cpp
)
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
set(HWASAN_RTL_HEADERS
hwasan.h
hwasan_allocator.h
hwasan_dynamic_shadow.h
hwasan_flags.h
hwasan_flags.inc
hwasan_interface_internal.h
Runtime flags for malloc bisection. Reviewers: kcc, pcc Subscribers: kubamracek, mgorny, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58162 llvm-svn: 354156
2019-02-16 02:38:14 +08:00
hwasan_malloc_bisect.h
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
hwasan_mapping.h
hwasan_poisoning.h
hwasan_report.h
[hwasan] Record and display stack history in stack-based reports. Summary: Display a list of recent stack frames (not a stack trace!) when tag-mismatch is detected on a stack address. The implementation uses alignment tricks to get both the address of the history buffer, and the base address of the shadow with a single 8-byte load. See the comment in hwasan_thread_list.h for more details. Developed in collaboration with Kostya Serebryany. Reviewers: kcc Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52249 llvm-svn: 342923
2018-09-25 07:03:34 +08:00
hwasan_thread.h
hwasan_thread_list.h
)
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-21 05:49:15 +08:00
set(HWASAN_DEFINITIONS)
append_list_if(COMPILER_RT_HWASAN_WITH_INTERCEPTORS HWASAN_WITH_INTERCEPTORS=1 HWASAN_DEFINITIONS)
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
set(HWASAN_RTL_CFLAGS ${SANITIZER_COMMON_CFLAGS})
append_rtti_flag(OFF HWASAN_RTL_CFLAGS)
[hwasan] Build runtime library with -fPIC, not -fPIE. Summary: -fPIE can not be used when building a shared library. Reviewers: alekseyshl, peter.smith Subscribers: kubamracek, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D42121 llvm-svn: 322588
2018-01-17 03:21:45 +08:00
append_list_if(COMPILER_RT_HAS_FPIC_FLAG -fPIC HWASAN_RTL_CFLAGS)
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
# Prevent clang from generating libc calls.
append_list_if(COMPILER_RT_HAS_FFREESTANDING_FLAG -ffreestanding HWASAN_RTL_CFLAGS)
set(HWASAN_DYNAMIC_LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS})
[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 HWASAN_DYNAMIC_LINK_FLAGS -Wl,-z,global)
endif()
endif()
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
set(HWASAN_DYNAMIC_CFLAGS ${HWASAN_RTL_CFLAGS})
append_list_if(COMPILER_RT_HAS_FTLS_MODEL_INITIAL_EXEC
-ftls-model=initial-exec HWASAN_DYNAMIC_CFLAGS)
append_list_if(MSVC /DEBUG HWASAN_DYNAMIC_LINK_FLAGS)
[compiler-rt] Cleanup usage of C++ ABI library Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Recommit r354132 which I reverted in r354153 because it broke a sanitizer bot. This was because of the "fixes" for pthread linking, so I've removed these changes. Differential Revision: https://reviews.llvm.org/D58012 llvm-svn: 354198
2019-02-16 16:34:26 +08:00
set(HWASAN_DYNAMIC_LIBS ${SANITIZER_CXX_ABI_LIBRARIES} ${SANITIZER_COMMON_LINK_LIBS})
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
append_list_if(COMPILER_RT_HAS_LIBDL dl HWASAN_DYNAMIC_LIBS)
append_list_if(COMPILER_RT_HAS_LIBRT rt HWASAN_DYNAMIC_LIBS)
append_list_if(COMPILER_RT_HAS_LIBM m HWASAN_DYNAMIC_LIBS)
append_list_if(COMPILER_RT_HAS_LIBPTHREAD pthread HWASAN_DYNAMIC_LIBS)
[CMake][ASan][HWASan] Set an explicit dependency on libc++ headers We have seen failing builds due to a race condition between RTAsan_dynamic and libc++ headers builds, specifically libc++ headers depend on __config and if this header hasn't been copied into the final location, including other headers will typically result in failure. To avoid this race, we add an explicit dependency on libc++ headers which ensures that they've been copied into place before the sanitizer object library build starts. Differential Revision: https://reviews.llvm.org/D54198 llvm-svn: 346339
2018-11-08 02:35:44 +08:00
if (TARGET cxx-headers OR HAVE_LIBCXX)
set(HWASAN_DEPS cxx-headers)
endif()
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
# Static runtime library.
add_compiler_rt_component(hwasan)
add_compiler_rt_object_libraries(RTHwasan
ARCHS ${HWASAN_SUPPORTED_ARCH}
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
SOURCES ${HWASAN_RTL_SOURCES}
ADDITIONAL_HEADERS ${HWASAN_RTL_HEADERS}
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-21 05:49:15 +08:00
CFLAGS ${HWASAN_RTL_CFLAGS}
[CMake][ASan][HWASan] Set an explicit dependency on libc++ headers We have seen failing builds due to a race condition between RTAsan_dynamic and libc++ headers builds, specifically libc++ headers depend on __config and if this header hasn't been copied into the final location, including other headers will typically result in failure. To avoid this race, we add an explicit dependency on libc++ headers which ensures that they've been copied into place before the sanitizer object library build starts. Differential Revision: https://reviews.llvm.org/D54198 llvm-svn: 346339
2018-11-08 02:35:44 +08:00
DEFS ${HWASAN_DEFINITIONS}
DEPS ${HWASAN_DEPS})
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
add_compiler_rt_object_libraries(RTHwasan_cxx
ARCHS ${HWASAN_SUPPORTED_ARCH}
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
SOURCES ${HWASAN_RTL_CXX_SOURCES}
ADDITIONAL_HEADERS ${HWASAN_RTL_HEADERS}
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-21 05:49:15 +08:00
CFLAGS ${HWASAN_RTL_CFLAGS}
[CMake][ASan][HWASan] Set an explicit dependency on libc++ headers We have seen failing builds due to a race condition between RTAsan_dynamic and libc++ headers builds, specifically libc++ headers depend on __config and if this header hasn't been copied into the final location, including other headers will typically result in failure. To avoid this race, we add an explicit dependency on libc++ headers which ensures that they've been copied into place before the sanitizer object library build starts. Differential Revision: https://reviews.llvm.org/D54198 llvm-svn: 346339
2018-11-08 02:35:44 +08:00
DEFS ${HWASAN_DEFINITIONS}
DEPS ${HWASAN_DEPS})
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
add_compiler_rt_object_libraries(RTHwasan_dynamic
ARCHS ${HWASAN_SUPPORTED_ARCH}
[CMake] Fix a typo in the variable used to retrieve source file names for the `RTHwasan_dynamic` target. Differential Revision: https://reviews.llvm.org/D49178 llvm-svn: 336944
2018-07-13 04:55:02 +08:00
SOURCES ${HWASAN_RTL_SOURCES} ${HWASAN_RTL_CXX_SOURCES}
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
ADDITIONAL_HEADERS ${HWASAN_RTL_HEADERS}
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-21 05:49:15 +08:00
CFLAGS ${HWASAN_DYNAMIC_CFLAGS}
[CMake][ASan][HWASan] Set an explicit dependency on libc++ headers We have seen failing builds due to a race condition between RTAsan_dynamic and libc++ headers builds, specifically libc++ headers depend on __config and if this header hasn't been copied into the final location, including other headers will typically result in failure. To avoid this race, we add an explicit dependency on libc++ headers which ensures that they've been copied into place before the sanitizer object library build starts. Differential Revision: https://reviews.llvm.org/D54198 llvm-svn: 346339
2018-11-08 02:35:44 +08:00
DEFS ${HWASAN_DEFINITIONS}
DEPS ${HWASAN_DEPS})
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
compiler-rt: Call a generated c++ file in hwasan .cpp instead of .cc llvm-svn: 367572
2019-08-01 22:48:16 +08:00
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp "")
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
add_compiler_rt_object_libraries(RTHwasan_dynamic_version_script_dummy
ARCHS ${HWASAN_SUPPORTED_ARCH}
compiler-rt: Call a generated c++ file in hwasan .cpp instead of .cc llvm-svn: 367572
2019-08-01 22:48:16 +08:00
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-21 05:49:15 +08:00
CFLAGS ${HWASAN_DYNAMIC_CFLAGS}
[CMake][ASan][HWASan] Set an explicit dependency on libc++ headers We have seen failing builds due to a race condition between RTAsan_dynamic and libc++ headers builds, specifically libc++ headers depend on __config and if this header hasn't been copied into the final location, including other headers will typically result in failure. To avoid this race, we add an explicit dependency on libc++ headers which ensures that they've been copied into place before the sanitizer object library build starts. Differential Revision: https://reviews.llvm.org/D54198 llvm-svn: 346339
2018-11-08 02:35:44 +08:00
DEFS ${HWASAN_DEFINITIONS}
DEPS ${HWASAN_DEPS})
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
foreach(arch ${HWASAN_SUPPORTED_ARCH})
add_compiler_rt_runtime(clang_rt.hwasan
STATIC
ARCHS ${arch}
OBJECT_LIBS RTHwasan
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
[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
RTUbsan
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
CFLAGS ${HWASAN_RTL_CFLAGS}
PARENT_TARGET hwasan)
add_compiler_rt_runtime(clang_rt.hwasan_cxx
STATIC
ARCHS ${arch}
OBJECT_LIBS RTHwasan_cxx
RTUbsan_cxx
CFLAGS ${HWASAN_RTL_CFLAGS}
PARENT_TARGET hwasan)
if (UNIX)
add_sanitizer_rt_version_list(clang_rt.hwasan-dynamic-${arch}
LIBS clang_rt.hwasan-${arch} clang_rt.hwasan_cxx-${arch}
EXTRA hwasan.syms.extra)
set(VERSION_SCRIPT_FLAG
-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/clang_rt.hwasan-dynamic-${arch}.vers)
set_property(SOURCE
compiler-rt: Call a generated c++ file in hwasan .cpp instead of .cc llvm-svn: 367572
2019-08-01 22:48:16 +08:00
${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
APPEND PROPERTY
OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang_rt.hwasan-dynamic-${arch}.vers)
else()
set(VERSION_SCRIPT_FLAG)
endif()
add_compiler_rt_runtime(clang_rt.hwasan
SHARED
ARCHS ${arch}
OBJECT_LIBS
RTHwasan_dynamic
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
[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
RTUbsan
[hwasan] Link ubsan_cxx to shared runtime library. Summary: This is needed for C++-specific ubsan and cfi error reporting to work. Reviewers: kcc, vitalybuka Subscribers: srhines, kubamracek, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D55589 llvm-svn: 348986
2018-12-13 06:56:00 +08:00
RTUbsan_cxx
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
# The only purpose of RTHWAsan_dynamic_version_script_dummy is to
# carry a dependency of the shared runtime on the version script.
# Replacing it with a straightforward
# add_dependencies(clang_rt.asan-dynamic-${arch} clang_rt.asan-dynamic-${arch}-version-list)
# generates an order-only dependency in ninja.
RTHwasan_dynamic_version_script_dummy
CFLAGS ${HWASAN_DYNAMIC_CFLAGS}
LINK_FLAGS ${HWASAN_DYNAMIC_LINK_FLAGS}
${VERSION_SCRIPT_FLAG}
LINK_LIBS ${HWASAN_DYNAMIC_LIBS}
DEFS ${ASAN_DYNAMIC_DEFINITIONS}
PARENT_TARGET hwasan)
[CMake] Build shared version of runtimes for Fuchsia Fuchsia is no longer treated as UNIX which means we need to explicitly enable building of shared versions of runtimes. Differential Revision: https://reviews.llvm.org/D46609 llvm-svn: 331922
2018-05-10 05:24:06 +08:00
if(SANITIZER_USE_SYMBOLS)
Hardware-assisted AddressSanitizer (compiler-rt) Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
2017-12-09 09:31:51 +08:00
add_sanitizer_rt_symbols(clang_rt.hwasan
ARCHS ${arch}
EXTRA hwasan.syms.extra)
add_sanitizer_rt_symbols(clang_rt.hwasan_cxx
ARCHS ${arch}
EXTRA hwasan.syms.extra)
add_dependencies(hwasan clang_rt.hwasan-${arch}-symbols
clang_rt.hwasan_cxx-${arch}-symbols)
endif()
endforeach()
add_compiler_rt_resource_file(hwasan_blacklist hwasan_blacklist.txt hwasan)
# if(COMPILER_RT_INCLUDE_TESTS)
# add_subdirectory(tests)
# endif()