replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/compiler-rt/lib/asan/CMakeLists.txt

343 lines
10 KiB
CMake
Raw Normal View History

Initial, very rough cut at a new CMake build system for compiler-rt. Some high-level notes: 1) An explicit goal is to support building compiler-rt as a subproject build, checked out into the projects/compiler-rt directory. There are many other possible ways of building the code here, but this is optimized for development on LLVM/Clang/compiler-rt, and incremental trial and testing of the toolchain. 2) The current support is targeted at Linux. I would love to see this generalized to other platforms, but for the sake of simplicity in testing, I'm focusing here first. Much of this patch was paired with Manuel, and I credit him with the majority of the work here. Some important caveats that I'll be working on in subsequent patches: 1) This uses the host compiler rather than using the just-built-clang. 2) Currently only x86 is supported. 3) Currently, none of the tests are built or run. 4) Uses CMake's builtin globbing which doesn't update correctly. 5) This is still turned off from LLVM's CMake build until these issues are addressed llvm-svn: 154060
2012-04-05 06:12:04 +08:00
# Build for the AddressSanitizer runtime support library.
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
set(ASAN_SOURCES
Rename asan_allocator2.cc to asan_allocator.cc llvm-svn: 224396
2014-12-17 08:26:50 +08:00
asan_allocator.cc
[asan] Implement delayed activation of AddressSanitizer This change adds ASAN_OPTIONS=start_deactivated=1 flag. When present, ASan will start in "deactivated" mode, with no heap poisoning, no quarantine, no stack trace gathering, and minimal redzones. All this features come back when __asan_init is called for the constructor of an instrumented library. The primary use case for this feature is Android. Code itself is not Android-specific, and this patch includes a Linux test for it. llvm-svn: 199377
2014-01-16 20:31:50 +08:00
asan_activation.cc
[ASan] Add ASan debugging API to get malloc/free stack traces and shadow memory mapping info Reviewed at http://reviews.llvm.org/D4466 llvm-svn: 213080
2014-07-16 01:33:23 +08:00
asan_debugging.cc
Split DescribeAddressIfShadow between a function that gets all the information, and one that prints it. Summary: Replacement for part of D23518 This is the first patch to start reifying information about errors. It deals only with reifying shadow address-related information. It will allow us to generate structures with all the relevant information for a given error so a debugger can get to them or they can be included in a core dump. Reviewers: kcc, samsonov Subscribers: kubabrecka, llvm-commits Differential Revision: https://reviews.llvm.org/D23519 llvm-svn: 278718
2016-08-16 03:30:21 +08:00
asan_descriptions.cc
Start reifying error descriptions (Re-do of D23672 supporting VS2013) Summary: @kcc: I know you've accepted the other revision, but since this is a non-trivial change, I'm updating it to show why D24029 would help. This commit sets up the infrastructure to use reified error descriptions, and moves ReportStackOverflow to the new system. After we convert all the errors, we'll be able to simplify ScopedInErrorReport and remove the older debugging mechanism which had some errors partly reified in some way. We'll be able to maintain the external API. ScopedInErrorReport will be able to track one of the reified errors at a time. The purpose of this is so we have its destructor actually print the error and possibly interface with the debugger (will depend on the platform, of course). Reviewers: kcc, samsonov, timurrrr Subscribers: kcc, llvm-commits, kubabrecka Differential Revision: https://reviews.llvm.org/D24030 llvm-svn: 280111
2016-08-31 01:08:55 +08:00
asan_errors.cc
[asan] move FakeStack into a separate file llvm-svn: 169734
2012-12-10 22:19:15 +08:00
asan_fake_stack.cc
[ASan] Move flag parsing logic to asan_flags.cc. NFC. llvm-svn: 224450
2014-12-18 03:31:39 +08:00
asan_flags.cc
[asan] Complete the Fuchsia port Submitted on behalf of Roland McGrath. Reviewers: kcc, eugenis, alekseyshl, vitalybuka Reviewed By: vitalybuka Subscribers: filcab, vitalybuka, srhines, kubamracek, mgorny, phosek, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D35865 llvm-svn: 310431
2017-08-09 08:21:45 +08:00
asan_fuchsia.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_globals.cc
[asan] Create a .ASAN$G(A-Z) section for global registration Summary: The expectation is that new instrumented code will add global variable metadata to the .ASAN$GL section, and we will use this new code to iterate over it. This technique seems to break when using incremental linking, which seems to align every global to a 256 byte boundary. Presumably this is so that it can incrementally cope with global changing size. Clang already passes -incremental:no as a linker flag when you invoke it to do the link step. The two tests added for this feature will fail until the LLVM instrumentation change in D26770 lands, so they are marked XFAIL for now. Reviewers: pcc, kcc, mehdi_amini, kubabrecka Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D26771 llvm-svn: 287246
2016-11-18 03:02:53 +08:00
asan_globals_win.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_interceptors.cc
[asan] Move memcpy, memmove, memset code out of asan_interceptors.cc This is a pure refactoring change. It simply moves all the code and macros related to defining the ASan interceptor versions of memcpy, memmove, and memset into a separate file. This makes it cleaner to disable all the other interceptor code while still using these three, for a port that defines these but not the other common interceptors. Reviewers: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35590 llvm-svn: 308575
2017-07-20 09:29:01 +08:00
asan_interceptors_memintrinsics.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_linux.cc
asan_mac.cc
asan_malloc_linux.cc
asan_malloc_mac.cc
asan_malloc_win.cc
[asan] add an interface function __sanitizer_print_memory_profile (a basic memory profiler; asan/Linux-only for now) llvm-svn: 271463
2016-06-02 09:21:52 +08:00
asan_memory_profile.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_poisoning.cc
asan_posix.cc
[asan] Use dynamic shadow on 32-bit Android, try 2. Summary: This change reverts r318575 and changes FindDynamicShadowStart() to keep the memory range it found mapped PROT_NONE to make sure it is not reused. We also skip MemoryRangeIsAvailable() check, because it is (a) unnecessary, and (b) would fail anyway. Reviewers: pcc, vitalybuka, kcc Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40203 llvm-svn: 318666
2017-11-21 01:41:57 +08:00
asan_premap_shadow.cc
[ASan] Move error reports away from ASan allocator. Add new source file to CMakeLists as well llvm-svn: 161569
2012-08-09 16:15:46 +08:00
asan_report.cc
[asan] Add target-specific files for Myriad RTEMS port Differential Revision: https://reviews.llvm.org/D46468 llvm-svn: 332691
2018-05-18 12:10:12 +08:00
asan_rtems.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_rtl.cc
[asan] Move shadow memory setup into its own file Submitted on behalf of Roland McGrath. Reviewers: vitalybuka, alekseyshl, kcc Subscribers: kubamracek, mgorny, phosek, filcab, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D36037 llvm-svn: 309542
2017-07-31 14:48:34 +08:00
asan_shadow_setup.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_stack.cc
asan_stats.cc
Implement AddressSanitizer suppressions. Adds 3 new suppression types, "interceptor_name", "interceptor_via_fun", "interceptor_via_lib". Reviewed at http://reviews.llvm.org/D6280. llvm-svn: 223508
2014-12-06 04:26:09 +08:00
asan_suppressions.cc
Resuming work on the compiler-rt CMake build at long long last. In order to get it working again, two changes were needed: - I had to give up on glob-based file expansion. This just isn't well supported by CMake, and until we convince upstream there of its value, it's not worth dealing with the pain. - Add the common library as otherwise even ASan won't build. This now builds again, although the "correctness" of it is a touch debatable. ;] Specifically, there is no merging of the common runtime library with the asan runtime library into a single archive file. I'm not really sure what the best technique is for that, and it may be influenced by the ongoing discussion about how best to link runtime libraries. Note of course that this is still very much WIP. It doesn't entirely work yet, and remains disabled by the LLVM projects/CMakeLists.txt until it is in a working state. llvm-svn: 158811
2012-06-20 18:18:43 +08:00
asan_thread.cc
Add cmake rules for building LSan common on Mac OS llvm-svn: 184639
2013-06-23 00:33:52 +08:00
asan_win.cc)
Initial, very rough cut at a new CMake build system for compiler-rt. Some high-level notes: 1) An explicit goal is to support building compiler-rt as a subproject build, checked out into the projects/compiler-rt directory. There are many other possible ways of building the code here, but this is optimized for development on LLVM/Clang/compiler-rt, and incremental trial and testing of the toolchain. 2) The current support is targeted at Linux. I would love to see this generalized to other platforms, but for the sake of simplicity in testing, I'm focusing here first. Much of this patch was paired with Manuel, and I credit him with the majority of the work here. Some important caveats that I'll be working on in subsequent patches: 1) This uses the host compiler rather than using the just-built-clang. 2) Currently only x86 is supported. 3) Currently, none of the tests are built or run. 4) Uses CMake's builtin globbing which doesn't update correctly. 5) This is still turned off from LLVM's CMake build until these issues are addressed llvm-svn: 154060
2012-04-05 06:12:04 +08:00
[sanitizer] Fix compilation errors in r355030. Disable hwasan interceptor on non-linux, non-x86-or-arm platforms. Add @plt to the asm call that clang intergrated-as infers but gcc does not. llvm-svn: 355041
2019-02-28 06:23:51 +08:00
if (NOT WIN32 AND NOT APPLE)
[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
list(APPEND ASAN_SOURCES asan_interceptors_vfork.S)
endif()
[ASan] Split static ASan runtime in two parts: asan and asan_cxx. asan_cxx containts replacements for new/delete operators, and should only be linked in C++ mode. We plan to start building this part with exception support to make new more standard-compliant. See https://code.google.com/p/address-sanitizer/issues/detail?id=295 for more details. llvm-svn: 208609
2014-05-13 02:39:22 +08:00
set(ASAN_CXX_SOURCES
asan_new_delete.cc)
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
set(ASAN_PREINIT_SOURCES
asan_preinit.cc)
[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(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
asan_thread.h)
Cleanup the handling of CFLAGS even more in the cmake build for ASan. Add the initial support for building ASan tests. The first change here is to try to get the CFLAGS to more closely match those used by the old Makefile. There are probably still goofs here, ASan folks, your review would be appreciated. The second big change is to add support for building both instrumentation based an non-instrumentation based unittests for ASan. They are built a bit differently from how the old makefiles managed things. Specifically, there are two binaries, one for the non-instrumented case, and one for the instrumented case. Also, the instrumented unit tests rely on the host compiler supporting AddressSanitizer's intrumentation pass. This is kind-of gross, but I don't know of a better way yet. I've mailed llvmdev to discuss this issue. One big caveat is that the detection logic currently doesn't work. I've commented it out temporarily as I'd like to get feedback from the ASan developers, etc. llvm-svn: 159134
2012-06-25 20:57:43 +08:00
include_directories(..)
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
set(ASAN_CFLAGS ${SANITIZER_COMMON_CFLAGS})
[asan] Add CMake hook to override shadow scale in compiler_rt Allow user to override shadow scale in compiler_rt by passing -DCOMPILER_RT_ASAN_SHADOW_SCALE=n to CMake. Propagate the override shadow scale value via a compiler define to compiler-rt and asan tests. Tests will use the define to partially disable unsupported tests. Set "-mllvm -asan-mapping-scale=<n>" for compiler_rt tests. Differential Revision: https://reviews.llvm.org/D39469 llvm-svn: 318038
2017-11-13 22:02:27 +08:00
set(ASAN_COMMON_DEFINITIONS ${COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION})
Add cmake build support for lsan on OS X Summary: Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan compilation and is turned off by default. Patches to fix build errors when this flag is enabled will be uploaded soon. This is part of an effort to port LSan to OS X, but LSan on OS X does not currently work or pass tests currently. Reviewers: kubamracek, kcc, glider, alekseyshl Reviewed By: kubamracek Subscribers: danalbert, srhines, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29783 llvm-svn: 295012
2017-02-14 08:56:53 +08:00
[cmake] Address Samsonov's post-commit review of r262723 Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
2016-03-05 18:01:04 +08:00
append_rtti_flag(OFF ASAN_CFLAGS)
[ASan] hoist more compile flags to SANITIZER_COMMON_CFLAGS var and add the rest of flags/defs from old Makefile to CMake llvm-svn: 163204
2012-09-05 17:00:03 +08:00
Support compiler-rt builtins This change adds support for compiler-rt builtins as an alternative compiler runtime to libgcc. Differential Revision: https://reviews.llvm.org/D35165 llvm-svn: 309361
2017-07-28 11:39:38 +08:00
set(ASAN_DYNAMIC_LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS})
Build ASan runtime library with -z global on Android. llvm-svn: 236537
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()
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
set(ASAN_DYNAMIC_DEFINITIONS
${ASAN_COMMON_DEFINITIONS} ASAN_DYNAMIC=1)
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
2014-10-16 06:47:54 +08:00
append_list_if(WIN32 INTERCEPTION_DYNAMIC_CRT ASAN_DYNAMIC_DEFINITIONS)
[ASan/Win] Intercept memory allocation functions in the MD CRT llvm-svn: 216382
2014-08-25 21:19:05 +08:00
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
set(ASAN_DYNAMIC_CFLAGS ${ASAN_CFLAGS})
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
2014-10-16 06:47:54 +08:00
append_list_if(COMPILER_RT_HAS_FTLS_MODEL_INITIAL_EXEC
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
-ftls-model=initial-exec ASAN_DYNAMIC_CFLAGS)
[compiler-rt] Fix the Asan unittest on Windows Summary: The build bot is broken because the runtime library doesn't have debug information. This is broken due to a recent change: http://reviews.llvm.org/D21554 Reviewers: rnk Subscribers: kubabrecka, llvm-commits, chrisha Differential Revision: http://reviews.llvm.org/D21862 llvm-svn: 274172
2016-06-30 05:54:50 +08:00
append_list_if(MSVC /DEBUG ASAN_DYNAMIC_LINK_FLAGS)
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
[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(ASAN_DYNAMIC_LIBS ${SANITIZER_CXX_ABI_LIBRARIES} ${SANITIZER_COMMON_LINK_LIBS})
Support compiler-rt builtins This change adds support for compiler-rt builtins as an alternative compiler runtime to libgcc. Differential Revision: https://reviews.llvm.org/D35165 llvm-svn: 309361
2017-07-28 11:39:38 +08:00
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
2014-10-16 06:47:54 +08:00
append_list_if(COMPILER_RT_HAS_LIBDL dl ASAN_DYNAMIC_LIBS)
Add descriptive names to sanitizer entries in /proc/self/maps. Helps debugging. This is done by creating a named shared memory region, unlinking it and setting up a private (i.e. copy-on-write) mapping of that instead of a regular anonymous mapping. I've experimented with regular (sparse) files, but they can not be scaled to the size of MSan shadow mapping, at least on Linux/X86_64 and ext3 fs. Controlled by a common flag, decorate_proc_maps, disabled by default. This patch has a few shortcomings: * not all mappings are annotated, especially in TSan. * our handling of memset() of shadow via mmap() puts small anonymous mappings inside larger named mappings, which looks ugly and can, in theory, hit the mapping number limit. llvm-svn: 238621
2015-05-30 06:31:28 +08:00
append_list_if(COMPILER_RT_HAS_LIBRT rt ASAN_DYNAMIC_LIBS)
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
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)
[asan] Only link liblog on Android when it exists. With r242975, liblog is only used on certain older platforms. llvm-svn: 243139
2015-07-25 03:00:16 +08:00
append_list_if(COMPILER_RT_HAS_LIBLOG log ASAN_DYNAMIC_LIBS)
[CMake] [MinGW] Build address sanitizer for MinGW if building with clang Differential Revision: https://reviews.llvm.org/D51885 llvm-svn: 343074
2018-09-26 14:53:01 +08:00
append_list_if(MINGW "${MINGW_LIBRARIES}" ASAN_DYNAMIC_LIBS)
[sanitizer] Android build cleanup. * Detect Android toolchain target arch and set correct runtime library name. * Merged a lot of Android and non-Android code paths. * Android is only supported in standalone build of compiler-rt now. * Linking lsan-common in ASan-Android (makes lsan annotations work). * Relying on -fsanitize=address linker flag when building tests (again, unification with non-Android path). * Runtime library moved from lib/asan to lib/linux. llvm-svn: 218605
2014-09-29 21:18:55 +08:00
[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(ASAN_DEPS cxx-headers)
endif()
[ASan] Split ASan unit tests into two different binaries: (1) instrumented, i.e. compiled and linked with -fsanitize=address (2) not instrumented, compiled w/o -fsanitize=address and linked with ASan runtime statically. llvm-svn: 190788
2013-09-16 23:50:53 +08:00
# Compile ASan sources into an object library.
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
add_compiler_rt_object_libraries(RTAsan_dynamic
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
OS ${SANITIZER_COMMON_SUPPORTED_OS}
ARCHS ${ASAN_SUPPORTED_ARCH}
SOURCES ${ASAN_SOURCES} ${ASAN_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 ${ASAN_HEADERS}
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
CFLAGS ${ASAN_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 ${ASAN_DYNAMIC_DEFINITIONS}
DEPS ${ASAN_DEPS})
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
if(NOT APPLE)
whitespaces + re-indent llvm-svn: 275023
2016-07-11 05:06:06 +08:00
add_compiler_rt_object_libraries(RTAsan
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
ARCHS ${ASAN_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 ${ASAN_SOURCES}
ADDITIONAL_HEADERS ${ASAN_HEADERS}
CFLAGS ${ASAN_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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
whitespaces + re-indent llvm-svn: 275023
2016-07-11 05:06:06 +08:00
add_compiler_rt_object_libraries(RTAsan_cxx
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
ARCHS ${ASAN_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 ${ASAN_CXX_SOURCES}
ADDITIONAL_HEADERS ${ASAN_HEADERS}
CFLAGS ${ASAN_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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
whitespaces + re-indent llvm-svn: 275023
2016-07-11 05:06:06 +08:00
add_compiler_rt_object_libraries(RTAsan_preinit
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
ARCHS ${ASAN_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 ${ASAN_PREINIT_SOURCES}
ADDITIONAL_HEADERS ${ASAN_HEADERS}
CFLAGS ${ASAN_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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
[asan] Fix build dependency issues with ASan version list file. CMake pre-3.1 has a bug where a shared library depending on a custom_target does not really depend on it. This commit implements a hilariously ugly workaround for this problem, see code comments for more details. llvm-svn: 238367
2015-05-28 06:38:01 +08:00
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cc "")
add_compiler_rt_object_libraries(RTAsan_dynamic_version_script_dummy
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
ARCHS ${ASAN_SUPPORTED_ARCH}
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/dummy.cc
CFLAGS ${ASAN_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 ${ASAN_DYNAMIC_DEFINITIONS}
DEPS ${ASAN_DEPS})
[ASan] Split ASan unit tests into two different binaries: (1) instrumented, i.e. compiled and linked with -fsanitize=address (2) not instrumented, compiled w/o -fsanitize=address and linked with ASan runtime statically. llvm-svn: 190788
2013-09-16 23:50:53 +08:00
endif()
# Build ASan runtimes shipped with Clang.
[CMake] Connect Compiler-RT targets to LLVM Runtimes directory This patch builds on LLVM r279776. In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth. The three steps I abstract are: (1) Add a top-level target (i.e asan, msan, ...) (2) Set the target properties for sorting files in IDE generators (3) Make the compiler-rt target depend on the top-level target The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name. The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings. With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is: > cmake [...] > ninja runtimes-configure > ninja asan The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build. Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats). llvm-svn: 279863
2016-08-27 04:52:22 +08:00
add_compiler_rt_component(asan)
missing modifications for http://reviews.llvm.org/D21952 llvm-svn: 275124
2016-07-12 07:09:33 +08:00
[ASan] CMake support for building ASan runtime as a universal binary on Mac llvm-svn: 161665
2012-08-10 22:45:52 +08:00
if(APPLE)
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
add_weak_symbols("asan" WEAK_SYMBOL_LINK_FLAGS)
Add cmake build support for lsan on OS X Summary: Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan compilation and is turned off by default. Patches to fix build errors when this flag is enabled will be uploaded soon. This is part of an effort to port LSan to OS X, but LSan on OS X does not currently work or pass tests currently. Reviewers: kubamracek, kcc, glider, alekseyshl Reviewed By: kubamracek Subscribers: danalbert, srhines, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29783 llvm-svn: 295012
2017-02-14 08:56:53 +08:00
add_weak_symbols("lsan" WEAK_SYMBOL_LINK_FLAGS)
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
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)
[Xray] Darwin improving slightly the support using sysctl to get the tic frequency data. still linkage issue for X-ray_init not resolved. Reviewers: dberris, kubamracek Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D51399 llvm-svn: 341019
2018-08-30 13:55:27 +08:00
add_weak_symbols("xray" WEAK_SYMBOL_LINK_FLAGS)
Enable weak hooks on darwin Summary: By default, darwin requires a definition for weak interface functions at link time. Adding the '-U' link flag with each weak function allows these weak interface functions to be used without definitions, which mirrors behavior on linux and windows. Reviewers: compnerd, eugenis Subscribers: kubabrecka, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28203 llvm-svn: 291417
2017-01-09 11:51:42 +08:00
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
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
[CMake] Unify build rules for sanitizer_common for Apple and non-Apple platforms. Additionally, link safestack runtime on OS X with nolibc version of sanitizer_common runtime, as we do on Linux. llvm-svn: 246227
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
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
RTLSanCommon
RTUbsan
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
LINK_FLAGS ${WEAK_SYMBOL_LINK_FLAGS}
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
DEFS ${ASAN_DYNAMIC_DEFINITIONS}
PARENT_TARGET asan)
[ASan] CMake support for building ASan runtime as a universal binary on Mac llvm-svn: 161665
2012-08-10 22:45:52 +08:00
else()
[ASan] Split ASan unit tests into two different binaries: (1) instrumented, i.e. compiled and linked with -fsanitize=address (2) not instrumented, compiled w/o -fsanitize=address and linked with ASan runtime statically. llvm-svn: 190788
2013-09-16 23:50:53 +08:00
# Build separate libraries for each target.
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
whitespaces + re-indent llvm-svn: 275023
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
whitespaces + re-indent llvm-svn: 275023
2016-07-11 05:06:06 +08:00
RTLSanCommon
RTUbsan)
cmake: fix the compiler-rt build with MSVC This sets flags and excludes things that aren't working with MSVC yet, allowing us to build the ASan runtime as part of the cmake build. Differential Revision: http://llvm-reviews.chandlerc.com/D1525 llvm-svn: 189304
2013-08-27 09:24:01 +08:00
whitespaces + re-indent llvm-svn: 275023
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)
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
whitespaces + re-indent llvm-svn: 275023
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)
[ASan] Split static ASan runtime in two parts: asan and asan_cxx. asan_cxx containts replacements for new/delete operators, and should only be linked in C++ mode. We plan to start building this part with exception support to make new more standard-compliant. See https://code.google.com/p/address-sanitizer/issues/detail?id=295 for more details. llvm-svn: 208609
2014-05-13 02:39:22 +08:00
whitespaces + re-indent llvm-svn: 275023
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)
[ASan] Always build shared ASan runtime on Linux. This commit changes the strategy for building shared ASan runtime and the way we test it: - COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now always build shared ASan runtime (it is the default on Android, Windows and Mac, and not the default on Linux and FreeBSD). - Platforms, which use static runtime by default now have "check-asan-dynamic" testsuite. This testsuite contains instrumented unit tests, and ASan lit tests, and runs them with shared ASan runtime. This testsuite is *not* a part of "check-asan" and *not* a part of "check-all", as adding 1000 more test cases, which duplicate existing ones is costly. However, you're welcome to add this command to your buildbot. llvm-svn: 224470
2014-12-18 07:14:01 +08:00
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
foreach(arch ${ASAN_SUPPORTED_ARCH})
[Sanitizers, CMake] Also use version script for libclang_rt.asan-i386.so When building LLVM on x86_64-pc-linux-gnu (Fedora 25) with the bundled gcc 6.4.1 which uses gld 2.26.1-1.fc25, the dynamic/Asan-i386-calls-Dynamic-Test and dynamic/Asan-i386-inline-Dynamic-Test tests failed to link with /usr/bin/ld: /var/scratch/gcc/llvm/dist/lib/clang/6.0.0/lib/linux/libclang_rt.asan-i386.so: fork: invalid version 21 (max 0) /var/scratch/gcc/llvm/dist/lib/clang/6.0.0/lib/linux/libclang_rt.asan-i386.so: error adding symbols: Bad value I tried building with a self-compiled gcc 7.1.0 using gld 2.28, but the error remained. It seems the error has been hit before (cf. https://reviews.llvm.org/rL314085), but no real explanation has been found. However, the problem goes away when linking the i386 libclang_rt.asan with a version script just like every other variant is. Not using the version script in this single case dates back to the initial introduction of the version script in r236551, but this change was just checked in without any explanation AFAICT. Since I've not found any other workaround and no reason for not always using the version script, I propose to do so. Tested on x86_64-pc-linux-gnu. Patch by Rainer Orth. Differential Revision: https://reviews.llvm.org/D39795 llvm-svn: 317738
2017-11-09 06:51:09 +08:00
if (UNIX)
[asan] Use a version script to limit the symbols exported by the ASan shared runtime library. llvm-svn: 236551
2015-05-06 06:51:35 +08:00
add_sanitizer_rt_version_list(clang_rt.asan-dynamic-${arch}
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
LIBS clang_rt.asan-${arch} clang_rt.asan_cxx-${arch}
[asan] Use a version script to limit the symbols exported by the ASan shared runtime library. llvm-svn: 236551
2015-05-06 06:51:35 +08:00
EXTRA asan.syms.extra)
[asan] Fix compiler-rt build. i386 runtime library was accidentally using the x86_64 version script without a dependency. llvm-svn: 236556
2015-05-06 07:13:50 +08:00
set(VERSION_SCRIPT_FLAG
[asan] Use a version script to limit the symbols exported by the ASan shared runtime library. llvm-svn: 236551
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.
if (OS_NAME MATCHES "SunOS")
list(APPEND VERSION_SCRIPT_FLAG -Wl,-z,gnu-version-script-compat)
endif()
Fix ASan version list dependency in multi-arch builds. Fixes PR32390. Patch by Andrey Krayniak. llvm-svn: 311394
2017-08-22 06:31:31 +08:00
set_property(SOURCE
[asan] Fix build dependency issues with ASan version list file. CMake pre-3.1 has a bug where a shared library depending on a custom_target does not really depend on it. This commit implements a hilariously ugly workaround for this problem, see code comments for more details. llvm-svn: 238367
2015-05-28 06:38:01 +08:00
${CMAKE_CURRENT_BINARY_DIR}/dummy.cc
Fix ASan version list dependency in multi-arch builds. Fixes PR32390. Patch by Andrey Krayniak. llvm-svn: 311394
2017-08-22 06:31:31 +08:00
APPEND PROPERTY
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang_rt.asan-dynamic-${arch}.vers)
[asan] Fix compiler-rt build. i386 runtime library was accidentally using the x86_64 version script without a dependency. llvm-svn: 236556
2015-05-06 07:13:50 +08:00
else()
set(VERSION_SCRIPT_FLAG)
[asan] Use a version script to limit the symbols exported by the ASan shared runtime library. llvm-svn: 236551
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)
[CMake] [MinGW] Build address sanitizer for MinGW if building with clang Differential Revision: https://reviews.llvm.org/D51885 llvm-svn: 343074
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}
build: repair cross-compilation with clang When building for Windows, we would check if we were using MSVC rather than WIN32. This resulted in needed targets not being defined by sanitizer_common. Fix the conditional. When registering the objects libraries for ASAN, we would multiply register for all targets as we were creating them inside a loop over all architectures. Only define the target per architecture. llvm-svn: 294510
2017-02-09 04:43:39 +08:00
ARCHS ${arch}
[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
SOURCES asan_win_weak_interception.cc
CFLAGS ${ASAN_CFLAGS} -DSANITIZER_DYNAMIC
[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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
[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()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
add_compiler_rt_runtime(clang_rt.asan
SHARED
ARCHS ${arch}
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
OBJECT_LIBS ${ASAN_COMMON_RUNTIME_OBJECT_LIBS}
RTAsan_dynamic
Fix ASan version list dependency in multi-arch builds. Fixes PR32390. Patch by Andrey Krayniak. llvm-svn: 311394
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
[asan] Fix build dependency issues with ASan version list file. CMake pre-3.1 has a bug where a shared library depending on a custom_target does not really depend on it. This commit implements a hilariously ugly workaround for this problem, see code comments for more details. llvm-svn: 238367
2015-05-28 06:38:01 +08:00
# add_dependencies(clang_rt.asan-dynamic-${arch} clang_rt.asan-dynamic-${arch}-version-list)
Fix ASan version list dependency in multi-arch builds. Fixes PR32390. Patch by Andrey Krayniak. llvm-svn: 311394
2017-08-22 06:31:31 +08:00
# generates an order-only dependency in ninja.
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
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}
[ASan] Always build shared ASan runtime on Linux. This commit changes the strategy for building shared ASan runtime and the way we test it: - COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now always build shared ASan runtime (it is the default on Android, Windows and Mac, and not the default on Linux and FreeBSD). - Platforms, which use static runtime by default now have "check-asan-dynamic" testsuite. This testsuite contains instrumented unit tests, and ASan lit tests, and runs them with shared ASan runtime. This testsuite is *not* a part of "check-asan" and *not* a part of "check-all", as adding 1000 more test cases, which duplicate existing ones is costly. However, you're welcome to add this command to your buildbot. llvm-svn: 224470
2014-12-18 07:14:01 +08:00
CFLAGS ${ASAN_DYNAMIC_CFLAGS}
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
LINK_FLAGS ${ASAN_DYNAMIC_LINK_FLAGS}
[asan] Fix compiler-rt build. i386 runtime library was accidentally using the x86_64 version script without a dependency. llvm-svn: 236556
2015-05-06 07:13:50 +08:00
${VERSION_SCRIPT_FLAG}
[CMake] fixing a typo that is breaking bots. llvm-svn: 245971
2015-08-26 04:00:35 +08:00
LINK_LIBS ${ASAN_DYNAMIC_LIBS}
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
DEFS ${ASAN_DYNAMIC_DEFINITIONS}
PARENT_TARGET asan)
[ASan] Optional support for dynamic ASan runtime on Linux. Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov! llvm-svn: 205308
2014-04-01 21:16:30 +08:00
[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 AND NOT ${arch} STREQUAL "i386")
[CMake] Add ARCHS option to add_sanitizer_rt_symbols. Summary: This is another step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt. Changes to CMakeLists files are all minimal except ubsan which tests the new ARCHS loop. Further cleanup patches will follow. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12410 llvm-svn: 246199
2015-08-28 04:07:54 +08:00
add_sanitizer_rt_symbols(clang_rt.asan_cxx
ARCHS ${arch})
[ASan] Split static ASan runtime in two parts: asan and asan_cxx. asan_cxx containts replacements for new/delete operators, and should only be linked in C++ mode. We plan to start building this part with exception support to make new more standard-compliant. See https://code.google.com/p/address-sanitizer/issues/detail?id=295 for more details. llvm-svn: 208609
2014-05-13 02:39:22 +08:00
add_dependencies(asan clang_rt.asan_cxx-${arch}-symbols)
[CMake] Add ARCHS option to add_sanitizer_rt_symbols. Summary: This is another step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt. Changes to CMakeLists files are all minimal except ubsan which tests the new ARCHS loop. Further cleanup patches will follow. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12410 llvm-svn: 246199
2015-08-28 04:07:54 +08:00
add_sanitizer_rt_symbols(clang_rt.asan
whitespaces + re-indent llvm-svn: 275023
2016-07-11 05:06:06 +08:00
ARCHS ${arch}
[CMake] Converting add_sanitizer_rt_symbols to use cmake_parse_arguments. Summary: This is the first step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12386 llvm-svn: 246102
2015-08-27 07:12:25 +08:00
EXTRA asan.syms.extra)
[ASan] Rename asan_runtime_libraries to asan. Re-enable tests on Android. llvm-svn: 201417
2014-02-14 22:45:13 +08:00
add_dependencies(asan clang_rt.asan-${arch}-symbols)
Generate list of symbols exported from sanitizer runtimes only on 64-bit Unix llvm-svn: 189454
2013-08-28 16:07:04 +08:00
endif()
cmake: fix the compiler-rt build with MSVC This sets flags and excludes things that aren't working with MSVC yet, allowing us to build the ASan runtime as part of the cmake build. Differential Revision: http://llvm-reviews.chandlerc.com/D1525 llvm-svn: 189304
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}
build: repair cross-compilation with clang When building for Windows, we would check if we were using MSVC rather than WIN32. This resulted in needed targets not being defined by sanitizer_common. Fix the conditional. When registering the objects libraries for ASAN, we would multiply register for all targets as we were creating them inside a loop over all architectures. Only define the target per architecture. llvm-svn: 294510
2017-02-09 04:43:39 +08:00
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
SOURCES asan_globals_win.cc
asan_win_dll_thunk.cc
CFLAGS ${ASAN_CFLAGS} -DSANITIZER_DLL_THUNK
[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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
[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
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
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}>
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
PARENT_TARGET asan)
[compiler-rt] Allow sanitizers to be compiled for windows with clang Summary: A few small changes required to permit building the sanitizers with Clang instead of only with MSVC. Reviewers: compnerd, beanz, rnk Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D24092 llvm-svn: 280863
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")
[compiler-rt] Allow sanitizers to be compiled for windows with clang Summary: A few small changes required to permit building the sanitizers with Clang instead of only with MSVC. Reviewers: compnerd, beanz, rnk Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D24092 llvm-svn: 280863
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}
build: repair cross-compilation with clang When building for Windows, we would check if we were using MSVC rather than WIN32. This resulted in needed targets not being defined by sanitizer_common. Fix the conditional. When registering the objects libraries for ASAN, we would multiply register for all targets as we were creating them inside a loop over all architectures. Only define the target per architecture. llvm-svn: 294510
2017-02-09 04:43:39 +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
SOURCES asan_globals_win.cc
asan_win_dynamic_runtime_thunk.cc
CFLAGS ${ASAN_CFLAGS} ${DYNAMIC_RUNTIME_THUNK_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 ${ASAN_COMMON_DEFINITIONS}
DEPS ${ASAN_DEPS})
[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
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
add_compiler_rt_runtime(clang_rt.asan_dynamic_runtime_thunk
[ASan/Win] Rename asan_win_uar_thunk.lib to asan_win_dynamic_runtime_thunk.lib It turned out that we have to bridge more stuff between the executable and the ASan RTL DLL than just __asan_option_detect_stack_use_after_return. See PR20918 for more details. llvm-svn: 217673
2014-09-12 21:21:02 +08:00
STATIC
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
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
[compiler-rt] Allow sanitizers to be compiled for windows with clang Summary: A few small changes required to permit building the sanitizers with Clang instead of only with MSVC. Reviewers: compnerd, beanz, rnk Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D24092 llvm-svn: 280863
2016-09-08 05:03:22 +08:00
CFLAGS ${ASAN_CFLAGS} ${DYNAMIC_RUNTIME_THUNK_CFLAGS}
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
DEFS ${ASAN_COMMON_DEFINITIONS}
PARENT_TARGET asan)
cmake: fix the compiler-rt build with MSVC This sets flags and excludes things that aren't working with MSVC yet, allowing us to build the ASan runtime as part of the cmake build. Differential Revision: http://llvm-reviews.chandlerc.com/D1525 llvm-svn: 189304
2013-08-27 09:24:01 +08:00
endif()
CMake: Generalize build rules for different arches for sanitizer_common, asan, ubsan llvm-svn: 172829
2013-01-19 00:51:07 +08:00
endforeach()
Initial, very rough cut at a new CMake build system for compiler-rt. Some high-level notes: 1) An explicit goal is to support building compiler-rt as a subproject build, checked out into the projects/compiler-rt directory. There are many other possible ways of building the code here, but this is optimized for development on LLVM/Clang/compiler-rt, and incremental trial and testing of the toolchain. 2) The current support is targeted at Linux. I would love to see this generalized to other platforms, but for the sake of simplicity in testing, I'm focusing here first. Much of this patch was paired with Manuel, and I credit him with the majority of the work here. Some important caveats that I'll be working on in subsequent patches: 1) This uses the host compiler rather than using the just-built-clang. 2) Currently only x86 is supported. 3) Currently, none of the tests are built or run. 4) Uses CMake's builtin globbing which doesn't update correctly. 5) This is still turned off from LLVM's CMake build until these issues are addressed llvm-svn: 154060
2012-04-05 06:12:04 +08:00
endif()
Cleanup the handling of CFLAGS even more in the cmake build for ASan. Add the initial support for building ASan tests. The first change here is to try to get the CFLAGS to more closely match those used by the old Makefile. There are probably still goofs here, ASan folks, your review would be appreciated. The second big change is to add support for building both instrumentation based an non-instrumentation based unittests for ASan. They are built a bit differently from how the old makefiles managed things. Specifically, there are two binaries, one for the non-instrumented case, and one for the instrumented case. Also, the instrumented unit tests rely on the host compiler supporting AddressSanitizer's intrumentation pass. This is kind-of gross, but I don't know of a better way yet. I've mailed llvmdev to discuss this issue. One big caveat is that the detection logic currently doesn't work. I've commented it out temporarily as I'd like to get feedback from the ASan developers, etc. llvm-svn: 159134
2012-06-25 20:57:43 +08:00
[CMake] Assign components and dependencies during add_compiler_rt_resource_file This makes it so that component-based installations will include resource files (i.e. blacklists). My next patch will add support for component-based installations. llvm-svn: 261699
2016-02-24 05:50:39 +08:00
add_compiler_rt_resource_file(asan_blacklist asan_blacklist.txt asan)
[ASan] Introduce a top-level target to collect all ASan runtimes and deps llvm-svn: 194696
2013-11-14 20:24:12 +08:00
[asan] Install asan_device_setup to bin/ when targetting Android. asan_device_setup is a utility that prepares a device to run code built with ASan. Essentially, it installs ASan runtime library into the system. For this reason, it has to be at a predictable relative path from the runtime library itself. We also plan to distribute this utility, packaged with runtime library and maybe llvm-symbolizer, to the users. llvm-svn: 202362
2014-02-27 16:41:40 +08:00
add_subdirectory(scripts)
[CMake] Introduce COMPILER_RT_INCLUDE_TESTS option llvm-svn: 201666
2014-02-19 19:18:47 +08:00
if(COMPILER_RT_INCLUDE_TESTS)
Cleanup the handling of CFLAGS even more in the cmake build for ASan. Add the initial support for building ASan tests. The first change here is to try to get the CFLAGS to more closely match those used by the old Makefile. There are probably still goofs here, ASan folks, your review would be appreciated. The second big change is to add support for building both instrumentation based an non-instrumentation based unittests for ASan. They are built a bit differently from how the old makefiles managed things. Specifically, there are two binaries, one for the non-instrumented case, and one for the instrumented case. Also, the instrumented unit tests rely on the host compiler supporting AddressSanitizer's intrumentation pass. This is kind-of gross, but I don't know of a better way yet. I've mailed llvmdev to discuss this issue. One big caveat is that the detection logic currently doesn't work. I've commented it out temporarily as I'd like to get feedback from the ASan developers, etc. llvm-svn: 159134
2012-06-25 20:57:43 +08:00
add_subdirectory(tests)
endif()