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

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

118 lines
4.1 KiB
CMake
Raw Normal View History

Allow compiler-rt test targets to work with multi-config CMake generators Multi-config CMake generators need lit to be able to resolve paths of artifacts from previous build steps at lit time, rather than expect them to be fully resolved at CMake time as they may contain the build mode. Differential Revision: https://reviews.llvm.org/D38471 llvm-svn: 318037
2017-11-13 20:57:54 +08:00
# Needed for lit support in standalone builds.
[CMake] Push the dependency on AddLLVM into the test and unites layers Compiler-rt only relies on LLVM for lit support. Pushing this dependency down into the test and unitest layers will allow builtin libraries to be built without LLVM. llvm-svn: 261105
2016-02-18 00:38:54 +08:00
include(AddLLVM)
[Compiler-rt] Distinguish between testing just built runtime libraries and the libraries shipped with the compiler. The path to the runtime libraries used by the compiler under test is normally identical to the path where just built libraries are created. However, this is not necessarily the case when doing standalone builds. This is because the external compiler used by tests may choose to get its runtime libraries from somewhere else. When doing standalone builds there are two types of testing we could be doing: * Test the just built runtime libraries. * Test the runtime libraries shipped with the compile under test. Both types of testing are valid but it confusingly turns out compiler-rt actually did a mixture of these types of testing. * The `test/builtins/Unit/` test suite always tested the just built runtime libraries. * All other testsuites implicitly use whatever runtime library the compiler decides to link. There is no way for us to infer which type of testing the developer wants so this patch introduces a new `COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` CMake option which explicitly declares which runtime libraries should be tested. If it is `ON` then the just built libraries should be tested, otherwise the libraries in the external compiler should be tested. When testing starts the lit test suite queries the compiler used for testing to see where it will get its runtime libraries from. If these paths are identical no action is taken (the common case). If the paths are not identical then we check the value of `COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` (progated into the config as `test_standalone_build_libs`) and check if the test suite supports testing in the requested configuration. * If we want to test just built libs and the test suite supports it (currently only `test/builtins/Unit`) then testing proceeds without any changes. * If we want to test the just built libs and the test suite doesn't support it we emit a fatal error to prevent the developer from testing the wrong runtime libraries. * If we are testing the compiler's built libs then we adjust `config.compiler_rt_libdir` to point at the compiler's runtime directory. This makes the `test/builtins/Unit` tests use the compiler's builtin library. No other changes are required because all other testsuites implicitly use the compiler's built libs. To make the above work the `test_suite_supports_overriding_runtime_lib_path` test suite config option has been introduced so we can identify what each test suite supports. Note all of these checks **have to be performed** when lit runs. We cannot run the checks at CMake generation time because multi-configuration build systems prevent us from knowing what the paths will be. We could perhaps support `COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` being `ON` for most test suites (when the runtime library paths differs) in the future by specifiying a custom compiler resource directory path. Doing so is out of scope for this patch. rdar://77182297 Differential Revision: https://reviews.llvm.org/D101681
2021-05-01 07:24:33 +08:00
option(COMPILER_RT_TEST_STANDALONE_BUILD_LIBS
"When set to ON and testing in a standalone build, test the runtime \
libraries built by this standalone build rather than the runtime libraries \
shipped with the compiler (used for testing). When set to OFF and testing \
in a standalone build, test the runtime libraries shipped with the compiler \
(used for testing). This option has no effect if the compiler and this \
build are configured to use the same runtime library path."
ON)
pythonize_bool(COMPILER_RT_TEST_STANDALONE_BUILD_LIBS)
[compiler-rt] Disable fuzzer large.test when LLVM_ENABLE_EXPENSIVE_CHECKS=ON This test is timing out on Green Dragon http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/ and looks like it's not executed on other bots with expensive checks enabled http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win The test times out at the C++ source file takes too long to build (2+ hours on my machine), as clang spends a lot of time in IR/MIR verifiers. Differential Revision: https://reviews.llvm.org/D70024
2019-12-04 06:34:02 +08:00
pythonize_bool(LLVM_ENABLE_EXPENSIVE_CHECKS)
Allow compiler-rt test targets to work with multi-config CMake generators Multi-config CMake generators need lit to be able to resolve paths of artifacts from previous build steps at lit time, rather than expect them to be fully resolved at CMake time as they may contain the build mode. Differential Revision: https://reviews.llvm.org/D38471 llvm-svn: 318037
2017-11-13 20:57:54 +08:00
configure_compiler_rt_lit_site_cfg(
Move shared configs for lit test suites to test/ and unittests/ directories llvm-svn: 201399
2014-02-14 19:00:07 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/lit.common.configured.in
${CMAKE_CURRENT_BINARY_DIR}/lit.common.configured)
Reapply r297382: "[compiler-rt][builtins] Add __isOSVersionAtLeast()" Looks like the problem was a case-insensitive include of dispatch/dispatch.h. llvm-svn: 297392
2017-03-10 01:02:16 +08:00
# BlocksRuntime (and most of builtins) testsuites are not yet ported to lit.
Move shared configs for lit test suites to test/ and unittests/ directories llvm-svn: 201399
2014-02-14 19:00:07 +08:00
# add_subdirectory(BlocksRuntime)
Move UBSan test suite under test/ llvm-svn: 201401
2014-02-14 19:42:22 +08:00
[CMake] Add the way to run tests in standalone build. 1) Depend on llvm-config (configured in LLVM_CONFIG_PATH) to get necessary LLVM source/binary directories. 2) Add basic support for running lit tests (check-xsan commands). For now this "support" is far from what we want: * unit tests are not built currently. * lit tests use Clang/compiler-rt from LLVM build directory, not the host compiler or just-built compiler-rt libraries. We should make a choice on the way we intend ti run compiler-rt lit testsuite: a) use either Clang from LLVM build tree, or the host compiler. b) use either just-built runtimes, or the runtimes shipped with the host compiler. Using just-built runtimes is tricky - we have to know where to put them, so that Clang/GCC driver would pick them up (and not overwrite the existing runtimes). Using a host compiler instead of Clang from LLVM build tree will give us a chance to run lit tests under GCC (which already has support for several sanitizers). That is, I tend to make the following choice: if we're in a standalone compiler-rt build, use host compiler with its set of runtime libraries to run lit tests. This will effectively decouple "make compiler-rt" and "make check-compiler-rt" in a standalone build - the latter wouldn't invoke the former. Note that if we decide to fix LLVM/Clang/compiler-rt build system so that it would configure/build compiler-rt with just-built Clang (as we do in Makefile-based build), this will not be a problem - we can add a dependency to ensure that clang/compiler-rt are rebuilt before running compiler-rt tests. llvm-svn: 201656
2014-02-19 18:04:29 +08:00
set(SANITIZER_COMMON_LIT_TEST_DEPS)
[asan] Enable asan_and_llvm_coverage_test.cc on Android Test just needs profile. llvm-svn: 313438
2017-09-16 11:26:03 +08:00
[cmake] Add a separate CMake var to control profile runtime Make it possible to control building profile runtime separately from other options. Before r313549, the profile runtime building was controlled along with sanitizers. However, since that commit it is built unconditionally which results in multiple builds for people building different runtimes separately. Differential Revision: https://reviews.llvm.org/D38441 llvm-svn: 314646
2017-10-02 13:03:55 +08:00
if(COMPILER_RT_BUILD_PROFILE AND COMPILER_RT_HAS_PROFILE)
[asan] Enable asan_and_llvm_coverage_test.cc on Android Test just needs profile. llvm-svn: 313438
2017-09-16 11:26:03 +08:00
list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS profile)
endif()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
# When ANDROID, we build tests with the host compiler (i.e. CMAKE_C_COMPILER),
# and run tests with tools from the host toolchain.
[CMake] Add the way to run tests in standalone build. 1) Depend on llvm-config (configured in LLVM_CONFIG_PATH) to get necessary LLVM source/binary directories. 2) Add basic support for running lit tests (check-xsan commands). For now this "support" is far from what we want: * unit tests are not built currently. * lit tests use Clang/compiler-rt from LLVM build directory, not the host compiler or just-built compiler-rt libraries. We should make a choice on the way we intend ti run compiler-rt lit testsuite: a) use either Clang from LLVM build tree, or the host compiler. b) use either just-built runtimes, or the runtimes shipped with the host compiler. Using just-built runtimes is tricky - we have to know where to put them, so that Clang/GCC driver would pick them up (and not overwrite the existing runtimes). Using a host compiler instead of Clang from LLVM build tree will give us a chance to run lit tests under GCC (which already has support for several sanitizers). That is, I tend to make the following choice: if we're in a standalone compiler-rt build, use host compiler with its set of runtime libraries to run lit tests. This will effectively decouple "make compiler-rt" and "make check-compiler-rt" in a standalone build - the latter wouldn't invoke the former. Note that if we decide to fix LLVM/Clang/compiler-rt build system so that it would configure/build compiler-rt with just-built Clang (as we do in Makefile-based build), this will not be a problem - we can add a dependency to ensure that clang/compiler-rt are rebuilt before running compiler-rt tests. llvm-svn: 201656
2014-02-19 18:04:29 +08:00
if(NOT ANDROID)
[CMake] Rename RUNTIMES_BUILD to LLVM_RUNTIMES_BUILD This avoid potential conflict with other internal variables. Differential Revision: https://reviews.llvm.org/D97838
2021-03-03 16:39:50 +08:00
if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
[CMake] Add the way to run tests in standalone build. 1) Depend on llvm-config (configured in LLVM_CONFIG_PATH) to get necessary LLVM source/binary directories. 2) Add basic support for running lit tests (check-xsan commands). For now this "support" is far from what we want: * unit tests are not built currently. * lit tests use Clang/compiler-rt from LLVM build directory, not the host compiler or just-built compiler-rt libraries. We should make a choice on the way we intend ti run compiler-rt lit testsuite: a) use either Clang from LLVM build tree, or the host compiler. b) use either just-built runtimes, or the runtimes shipped with the host compiler. Using just-built runtimes is tricky - we have to know where to put them, so that Clang/GCC driver would pick them up (and not overwrite the existing runtimes). Using a host compiler instead of Clang from LLVM build tree will give us a chance to run lit tests under GCC (which already has support for several sanitizers). That is, I tend to make the following choice: if we're in a standalone compiler-rt build, use host compiler with its set of runtime libraries to run lit tests. This will effectively decouple "make compiler-rt" and "make check-compiler-rt" in a standalone build - the latter wouldn't invoke the former. Note that if we decide to fix LLVM/Clang/compiler-rt build system so that it would configure/build compiler-rt with just-built Clang (as we do in Makefile-based build), this will not be a problem - we can add a dependency to ensure that clang/compiler-rt are rebuilt before running compiler-rt tests. llvm-svn: 201656
2014-02-19 18:04:29 +08:00
# Use LLVM utils and Clang from the same build tree.
list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS
[build] Rename clang-headers to clang-resource-headers Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
2019-03-05 05:19:53 +08:00
clang clang-resource-headers FileCheck count not llvm-config llvm-nm llvm-objdump
[ORC-RT] Add target dependencies to ORC-RT regression tests. check-orc-rt had no cmake target dependency on orc or llvm-jitlink, which could lead to regression test failures in compiler-rt. This patch should fix the issue. Patch by Jack Andersen (jackoalan@gmail.com). Thanks Jack! Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D110659
2021-09-29 13:08:47 +08:00
llvm-readelf llvm-readobj llvm-size llvm-symbolizer compiler-rt-headers sancov
llvm-jitlink)
UBSan: Enable runtime library tests on Windows, and get most tests passing. Specifically: - Disable int128 tests on Windows, as MSVC cl.exe does not support int128, so we might not have been able to build the runtime with int128 support. - XFAIL the vptr tests as we lack Microsoft ABI support. - XFAIL enum.cpp as UBSan fails to add the correct instrumentation code for some reason. - Modify certain tests that build executables multiple times to use unique names for each executable. This works around a race condition observed on Windows. - Implement IsAccessibleMemoryRange for Windows to fix the last misaligned.cpp test. - Introduce a substitution for testing crashes on Windows using KillTheDoctor. Differential Revision: http://reviews.llvm.org/D10864 llvm-svn: 241303
2015-07-03 06:08:38 +08:00
if (WIN32)
list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS KillTheDoctor)
endif()
[CMake] Add the way to run tests in standalone build. 1) Depend on llvm-config (configured in LLVM_CONFIG_PATH) to get necessary LLVM source/binary directories. 2) Add basic support for running lit tests (check-xsan commands). For now this "support" is far from what we want: * unit tests are not built currently. * lit tests use Clang/compiler-rt from LLVM build directory, not the host compiler or just-built compiler-rt libraries. We should make a choice on the way we intend ti run compiler-rt lit testsuite: a) use either Clang from LLVM build tree, or the host compiler. b) use either just-built runtimes, or the runtimes shipped with the host compiler. Using just-built runtimes is tricky - we have to know where to put them, so that Clang/GCC driver would pick them up (and not overwrite the existing runtimes). Using a host compiler instead of Clang from LLVM build tree will give us a chance to run lit tests under GCC (which already has support for several sanitizers). That is, I tend to make the following choice: if we're in a standalone compiler-rt build, use host compiler with its set of runtime libraries to run lit tests. This will effectively decouple "make compiler-rt" and "make check-compiler-rt" in a standalone build - the latter wouldn't invoke the former. Note that if we decide to fix LLVM/Clang/compiler-rt build system so that it would configure/build compiler-rt with just-built Clang (as we do in Makefile-based build), this will not be a problem - we can add a dependency to ensure that clang/compiler-rt are rebuilt before running compiler-rt tests. llvm-svn: 201656
2014-02-19 18:04:29 +08:00
endif()
[CMake] Include dependency on cxx-headers in compiler-rt tests The missing dependency was revealed by D97572. Differential Revision: https://reviews.llvm.org/D99706
2021-04-01 14:23:20 +08:00
# Tests use C++ standard library headers.
if (TARGET cxx-headers OR HAVE_LIBCXX)
[CMake] Use append instead of set with the list This addresses an issue introduced by D99706.
2021-04-02 11:30:49 +08:00
list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS cxx-headers)
[CMake] Include dependency on cxx-headers in compiler-rt tests The missing dependency was revealed by D97572. Differential Revision: https://reviews.llvm.org/D99706
2021-04-01 14:23:20 +08:00
endif()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
endif()
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
function(compiler_rt_test_runtime runtime)
string(TOUPPER ${runtime} runtime_uppercase)
if(COMPILER_RT_HAS_${runtime_uppercase})
add_subdirectory(${runtime})
foreach(directory ${ARGN})
add_subdirectory(${directory})
endforeach()
endif()
endfunction()
Move UBSan test suite under test/ llvm-svn: 201401
2014-02-14 19:42:22 +08:00
# Run sanitizer tests only if we're sure that clang would produce
# working binaries.
if(COMPILER_RT_CAN_EXECUTE_TESTS)
Reapply r297382: "[compiler-rt][builtins] Add __isOSVersionAtLeast()" Looks like the problem was a case-insensitive include of dispatch/dispatch.h. llvm-svn: 297392
2017-03-10 01:02:16 +08:00
if(COMPILER_RT_BUILD_BUILTINS)
add_subdirectory(builtins)
endif()
[test] Build sanitizer/xray tests only if COMPILER_RT_BUILD_* is on Cover the sanitizer tests with COMPILER_RT_BUILD_SANITIZERS conditional, and add COMPILER_RT_BUILD_XRAY conditional to the xray tests. This makes it possible to do a pure-builtins build with tests enabled. Differential Revision: https://reviews.llvm.org/D32489 llvm-svn: 301387
2017-04-26 15:35:36 +08:00
if(COMPILER_RT_BUILD_SANITIZERS)
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
compiler_rt_test_runtime(interception)
compiler_rt_test_runtime(lsan)
Revert "Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used" This breaks cfi testing in cases when the cfi runtime isn't built. This reverts commit 1c6a7b07545f0c9ce68e8b226f5397694ce48af7. llvm-svn: 306431
2017-06-28 01:24:26 +08:00
# CFI tests require diagnostic mode, which is implemented in UBSan.
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
compiler_rt_test_runtime(ubsan cfi)
compiler_rt_test_runtime(sanitizer_common)
[fuzzer] Don't enable tests when the fuzzer isn't built Should fix: http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1527 llvm-svn: 312157
2017-08-31 03:29:11 +08:00
libFuzzer, OpenBSD support Summary: - Enabling libfuzzer on OpenBSD - OpenBSD can t support asan, msan ... the tests can t be run. Patch by David CARLIER Reviewers: eugenis, phosek, vitalybuka Reviewed By: vitalybuka Subscribers: srhines, mgorny, krytarowski, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D44877 llvm-svn: 329631
2018-04-10 06:38:26 +08:00
# OpenBSD not supporting asan, cannot run the tests
[libFuzzer] Enable tests on Windows Summary: Enable tests on Windows and make check-fuzzer pass on it. Make check-fuzzer pass on Windows by fixing libFuzzer, fixing tests, and by disabling tests on Windows. Most of these are disabled temporarily as support for the tests and the features they test will be added incrementally. Other tests will not be enabled since they require things that are not on Windows (eg: afl_driver tests). Every test that was explicitly disabled on Windows has a comment explaining why (unless obvious like merge-posix.test). The lit.cfg file was modified to support running tests on windows. fuzzer-dirs.test was fixed by making the Windows implementation print the same error message as the posix version. merge-control-file.test was fixed by making the test binary end with the ".exe" extension (on all platforms). Patch By: metzman Reviewers: morehouse Reviewed By: morehouse Subscribers: srhines, mgorny Differential Revision: https://reviews.llvm.org/D51549 llvm-svn: 341385
2018-09-05 01:08:47 +08:00
if(COMPILER_RT_BUILD_LIBFUZZER AND NOT "${CMAKE_SYSTEM_NAME}" STREQUAL "OpenBSD" AND NOT ANDROID)
[fuzzer] Don't enable tests when the fuzzer isn't built Should fix: http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1527 llvm-svn: 312157
2017-08-31 03:29:11 +08:00
compiler_rt_test_runtime(fuzzer)
endif()
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
Loop directly over sanitizers to build in cmake Summary: Cleaner than computing the intersection for each possible sanitizer Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34693 llvm-svn: 306453
2017-06-28 03:32:39 +08:00
foreach(sanitizer ${COMPILER_RT_SANITIZERS_TO_BUILD})
Don't double-include cfi tests on linux llvm-svn: 306455
2017-06-28 03:52:35 +08:00
# cfi testing is gated on ubsan
if(NOT ${sanitizer} STREQUAL cfi)
compiler_rt_test_runtime(${sanitizer})
endif()
Loop directly over sanitizers to build in cmake Summary: Cleaner than computing the intersection for each possible sanitizer Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34693 llvm-svn: 306453
2017-06-28 03:32:39 +08:00
endforeach()
[cmake] Make it possible to build and test profile without sanitizers This should fix an issue which arises when running check-compiler-rt on the coverage bot: http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1590/ The bot doesn't build the sanitizers, but the check-compiler-rt target always expects the profile runtime to exist. llvm-svn: 313549
2017-09-19 02:13:47 +08:00
endif()
[cmake] Add a separate CMake var to control profile runtime Make it possible to control building profile runtime separately from other options. Before r313549, the profile runtime building was controlled along with sanitizers. However, since that commit it is built unconditionally which results in multiple builds for people building different runtimes separately. Differential Revision: https://reviews.llvm.org/D38441 llvm-svn: 314646
2017-10-02 13:03:55 +08:00
if(COMPILER_RT_BUILD_PROFILE AND COMPILER_RT_HAS_PROFILE)
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
compiler_rt_test_runtime(profile)
[sanitizer] Initial implementation of a Hardened Allocator Summary: This is an initial implementation of a Hardened Allocator based on Sanitizer Common's CombinedAllocator. It aims at mitigating heap based vulnerabilities by adding several features to the base allocator, while staying relatively fast. The following were implemented: - additional consistency checks on the allocation function parameters and on the heap chunks; - use of checksum protected chunk header, to detect corruption; - randomness to the allocator base; - delayed freelist (quarantine), to mitigate use after free and overall determinism. Additional mitigations are in the works. Reviewers: eugenis, aizatsky, pcc, krasin, vitalybuka, glider, dvyukov, kcc Subscribers: kubabrecka, filcab, llvm-commits Differential Revision: http://reviews.llvm.org/D20084 llvm-svn: 271968
2016-06-07 09:20:26 +08:00
endif()
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120
2020-09-04 06:21:20 +08:00
if(COMPILER_RT_BUILD_MEMPROF)
compiler_rt_test_runtime(memprof)
endif()
Only test sanitizers that are built when COMPILER_RT_SANITIZERS_TO_BUILD is used Summary: This allows check-all to be used when only a subset of the sanitizers are built. Reviewers: beanz, compnerd, rnk, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D34644 llvm-svn: 306450
2017-06-28 03:18:01 +08:00
if(COMPILER_RT_BUILD_XRAY)
compiler_rt_test_runtime(xray)
[compiler-rt][XRay] Implement __xray_unpatch() and __xray_remove_handler() Summary: We also add one test (and the XRay testing infrastructure) to exercise the patching and unpatching code. This uses the XRay API exported through the headers as well, installing a custom log handler. Depends on D23101 for the updated emitted code alignment for the return/entry sleds. Reviewers: rSerge, echristo, rnk Subscribers: tberghammer, danalbert, srhines, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23154 llvm-svn: 277971
2016-08-08 11:10:22 +08:00
endif()
[ORC-RT] Re-apply "Initial ORC Runtime directories and build..." with fixes. This reapplies 1e1d75b190c, which was reverted in ce1a4d53231 due to build failures. The unconditional dependencies on clang and llvm-jitlink in compiler-rt/test/orc/CMakeLists.txt have been removed -- they don't appear to be necessary, and I suspect they're the cause of the build failures seen earlier.
2021-04-24 12:14:56 +08:00
if(COMPILER_RT_BUILD_ORC)
compiler_rt_Test_runtime(orc)
endif()
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" Clang relies on existence of certain symbols that are normally provided by crtbegin.o/crtend.o. However, LLVM does not currently provide implementation of these files, instead relying on either libgcc or implementations provided as part of the system. This change provides an initial implementation of crtbegin.o/crtend.o that can be used on system that don't provide crtbegin.o/crtend.o as part of their C library. Differential Revision: https://reviews.llvm.org/D28791 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
if(COMPILER_RT_BUILD_CRT AND COMPILER_RT_HAS_CRT)
add_subdirectory(crt)
endif()
Add simple runtime tests for shadowcallstack Summary: ShadowCallStack does not yet have a runtime provided by compiler-rt, but this change includes simple tests that make use of a very minimal runtime in test/shadowcallstack/minimal_runtime.h Reviewers: pcc, kcc, delcypher, eugenis, filcab Reviewed By: pcc Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D44803 llvm-svn: 329210
2018-04-05 01:53:33 +08:00
# ShadowCallStack does not yet provide a runtime with compiler-rt, the tests
# include their own minimal runtime
add_subdirectory(shadowcallstack)
Move UBSan test suite under test/ llvm-svn: 201401
2014-02-14 19:42:22 +08:00
endif()
[CMake] Introduce check-all command for standalone compiler-rt build llvm-svn: 201780
2014-02-20 20:36:26 +08:00
if(COMPILER_RT_STANDALONE_BUILD)
# Now that we've traversed all the directories and know all the lit testsuites,
# introduce a rule to run to run all of them.
get_property(LLVM_LIT_TESTSUITES GLOBAL PROPERTY LLVM_LIT_TESTSUITES)
get_property(LLVM_LIT_DEPENDS GLOBAL PROPERTY LLVM_LIT_DEPENDS)
Partially revert "[runtimes] Use add_lit_testsuite to register lit testsuites" This partially reverts commit e1173c8794f4942d2cdddb090489ba5a6cc193e8 until we find out why compiler-rt tests are failing under runtimes build.
2021-03-06 07:24:38 +08:00
add_lit_target(check-compiler-rt
[CMake] Introduce check-all command for standalone compiler-rt build llvm-svn: 201780
2014-02-20 20:36:26 +08:00
"Running all regression tests"
${LLVM_LIT_TESTSUITES}
DEPENDS ${LLVM_LIT_DEPENDS})
[CMake] Add check-compiler-rt target for runtimes build Durning standalone builds (which includes runtimes builds) we want to create a target named check-compiler-rt. Additionally we also create check-all if it doesn't already exist as a convienence target that depends on check-compiler-rt. This allows us to generate a single check target that invokes lit for all test suites in the runtimes projects, while avoiding name collision of check-all and not breaking existing workflows. llvm-svn: 279334
2016-08-20 06:17:48 +08:00
if(NOT TARGET check-all)
add_custom_target(check-all)
endif()
[CMake] Adding compiler-rt-test-depends target This exposes a target for building the compiler-rt test dependencies and matches llvm-test-depends. llvm-svn: 280393
2016-09-02 02:26:51 +08:00
add_custom_target(compiler-rt-test-depends DEPENDS ${LLVM_LIT_DEPENDS})
[CMake] Add check-compiler-rt target for runtimes build Durning standalone builds (which includes runtimes builds) we want to create a target named check-compiler-rt. Additionally we also create check-all if it doesn't already exist as a convienence target that depends on check-compiler-rt. This allows us to generate a single check target that invokes lit for all test suites in the runtimes projects, while avoiding name collision of check-all and not breaking existing workflows. llvm-svn: 279334
2016-08-20 06:17:48 +08:00
add_dependencies(check-all check-compiler-rt)
[CMake] Introduce check-all command for standalone compiler-rt build llvm-svn: 201780
2014-02-20 20:36:26 +08:00
endif()