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

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

78 lines
2.1 KiB
CMake
Raw Normal View History

Another big step toward a viable CMake build system for CompilerRT, ASan, and friends. This explicitly switches the CompilerRT CMake build to require CMake version 2.8.8 or newer which provides first-class support for "object" libraries which consist of a pile of '.o' files -- exactly what is desired for composing runtime libraries. I've gone ahead and switched to using this. I've also added the interception library which I missed initially. And I've added proper dependencies between the various libraries. With this, I'm able to build archives for asan that appear to contain all of the necessary .o files. The final tweak here is to start setting up the compile flags and macro defines expected by ASan and its helper libraries. These may not be entirely correct currently, they're based loosely on my reading of the old Makefiles. However, they can be tweaked more easily now that they're wired up properly. llvm-svn: 159129
2012-06-25 16:40:10 +08:00
# First, add the subdirectories which contain feature-based runtime libraries
# and several convenience helper libraries.
[CMake] Don't build sanitizer runtimes if LLVM_USE_SANITIZER is specified llvm-svn: 189745
2013-09-02 16:57:23 +08:00
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 15:26:58 +08:00
include(AddCompilerRT)
include(SanitizerUtils)
[CMake] Determine which compiler-rt libraries are supported on a given platform in a top-level CMakeLists.txt to use it both in lib/ and in test/ subdirectories. Move architecture/platform checks to config-ix. llvm-svn: 215247
2014-08-09 06:01:20 +08:00
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due to extraneous and missing dependencies and attempts to build on unsupported OSes Summary: This is a fixed-up version of D21612, to address failure identified post-commit. Original commit description: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Fixes include: - Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built - Including <cstddef> to fix std::size_t issue Reviewers: kcc, rnk, echristo Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22611 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
# Hoist the building of sanitizer_common on whether we're building either the
# sanitizers or xray (or both).
#
#TODO: Refactor sanitizer_common into smaller pieces (e.g. flag parsing, utils).
if (COMPILER_RT_HAS_SANITIZER_COMMON AND
[MemProf] Decouple memprof build from COMPILER_RT_BUILD_SANITIZERS The MemProf compiler-rt support relies on some of the support only built when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some initial bot failures, and I addressed those by making the memprof runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS (3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b). However, this resulted in another inconsistency with how the tests were set up that was hit by Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1142191 Undo the original bot fix and address this with a more comprehensive fix that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS is disabled, by also building the necessary pieces under COMPILER_RT_BUILD_MEMPROF. Tested by configuring with a similar command as to what was used in the failing Chromium configure. I reproduced the Chromium failure, as well as the original bot failure I tried to fix in 3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b, with that fix reverted. Confirmed it now works. Differential Revision: https://reviews.llvm.org/D90190
2020-10-27 04:36:01 +08:00
(COMPILER_RT_BUILD_SANITIZERS OR COMPILER_RT_BUILD_XRAY OR COMPILER_RT_BUILD_MEMPROF))
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due to extraneous and missing dependencies and attempts to build on unsupported OSes Summary: This is a fixed-up version of D21612, to address failure identified post-commit. Original commit description: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Fixes include: - Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built - Including <cstddef> to fix std::size_t issue Reviewers: kcc, rnk, echristo Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22611 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
add_subdirectory(sanitizer_common)
endif()
[CMake] Add options to control building sanitizers and builtins. There are situations where a user may want to build only the compiler-rt builtins, or only the sanitizer runtimes. This exposes options to do that. Both default to On, so there should be no implicit change in behavior. llvm-svn: 247607
2015-09-15 03:59:24 +08:00
if(COMPILER_RT_BUILD_BUILTINS)
add_subdirectory(builtins)
endif()
[CMake][compiler-rt] Make CRT separately buildable This is useful when building a complete toolchain to ensure that CRT is built after builtins but before the rest of the compiler-rt. Differential Revision: https://reviews.llvm.org/D120682
2022-03-01 04:21:11 +08:00
if(COMPILER_RT_BUILD_CRT)
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
add_subdirectory(crt)
endif()
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
function(compiler_rt_build_runtime runtime)
string(TOUPPER ${runtime} runtime_uppercase)
if(COMPILER_RT_HAS_${runtime_uppercase})
add_subdirectory(${runtime})
Don't build tsan/dd when COMPILER_RT_HAS_TSAN is false llvm-svn: 306463
2017-06-28 05:10:46 +08:00
if(${runtime} STREQUAL tsan)
add_subdirectory(tsan/dd)
endif()
[scudo] Initial standalone skeleton check-in Summary: This is the initial check-in for the Standalone version of Scudo. The project is initially going to live in scudo/standalone then will replace scudo. See http://lists.llvm.org/pipermail/llvm-dev/2019-January/129113.html for details. This initial CL is meant to lay out the project structure, of both code & tests, providing a minimal amount of functionalities, namely various definitions, some atomic helpers and an intrusive list. (empty.cc is just here to have a compilation unit, but will go away in the upcoming CLs). Initial support is restricted to Linux i386 & x86_64 in make files and will be extended once things land & work. We will grow organically from here, adding functionalities in limited amounts. Reviewers: morehouse, eugenis, vitalybuka, kcc, mcgrathr, flowerhack Reviewed By: morehouse, vitalybuka Subscribers: srhines, mgorny, krytarowski, delcypher, jfb, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D57412 llvm-svn: 353055
2019-02-05 00:25:40 +08:00
if(${runtime} STREQUAL scudo)
add_subdirectory(scudo/standalone)
endif()
Revert "[CMake] Provide options for toggling on and off various runtime libraries." This reverts r255170. This change caused a bunch of bot failures and needs to be revised. llvm-svn: 255184
2015-12-10 08:40:58 +08:00
endif()
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
endfunction()
[MemProf] Decouple memprof build from COMPILER_RT_BUILD_SANITIZERS The MemProf compiler-rt support relies on some of the support only built when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some initial bot failures, and I addressed those by making the memprof runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS (3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b). However, this resulted in another inconsistency with how the tests were set up that was hit by Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1142191 Undo the original bot fix and address this with a more comprehensive fix that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS is disabled, by also building the necessary pieces under COMPILER_RT_BUILD_MEMPROF. Tested by configuring with a similar command as to what was used in the failing Chromium configure. I reproduced the Chromium failure, as well as the original bot failure I tried to fix in 3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b, with that fix reverted. Confirmed it now works. Differential Revision: https://reviews.llvm.org/D90190
2020-10-27 04:36:01 +08:00
if(COMPILER_RT_BUILD_SANITIZERS OR COMPILER_RT_BUILD_MEMPROF)
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
compiler_rt_build_runtime(interception)
[MemProf] Decouple memprof build from COMPILER_RT_BUILD_SANITIZERS The MemProf compiler-rt support relies on some of the support only built when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some initial bot failures, and I addressed those by making the memprof runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS (3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b). However, this resulted in another inconsistency with how the tests were set up that was hit by Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1142191 Undo the original bot fix and address this with a more comprehensive fix that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS is disabled, by also building the necessary pieces under COMPILER_RT_BUILD_MEMPROF. Tested by configuring with a similar command as to what was used in the failing Chromium configure. I reproduced the Chromium failure, as well as the original bot failure I tried to fix in 3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b, with that fix reverted. Confirmed it now works. Differential Revision: https://reviews.llvm.org/D90190
2020-10-27 04:36:01 +08:00
endif()
Revert "[CMake] Provide options for toggling on and off various runtime libraries." This reverts r255170. This change caused a bunch of bot failures and needs to be revised. llvm-svn: 255184
2015-12-10 08:40:58 +08:00
[MemProf] Decouple memprof build from COMPILER_RT_BUILD_SANITIZERS The MemProf compiler-rt support relies on some of the support only built when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some initial bot failures, and I addressed those by making the memprof runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS (3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b). However, this resulted in another inconsistency with how the tests were set up that was hit by Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1142191 Undo the original bot fix and address this with a more comprehensive fix that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS is disabled, by also building the necessary pieces under COMPILER_RT_BUILD_MEMPROF. Tested by configuring with a similar command as to what was used in the failing Chromium configure. I reproduced the Chromium failure, as well as the original bot failure I tried to fix in 3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b, with that fix reverted. Confirmed it now works. Differential Revision: https://reviews.llvm.org/D90190
2020-10-27 04:36:01 +08:00
if(COMPILER_RT_BUILD_SANITIZERS)
Revert "[CMake] Provide options for toggling on and off various runtime libraries." This reverts r255170. This change caused a bunch of bot failures and needs to be revised. llvm-svn: 255184
2015-12-10 08:40:58 +08:00
if(COMPILER_RT_HAS_SANITIZER_COMMON)
Introduce stats and stats_client libraries. This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16176 llvm-svn: 257972
2016-01-16 08:31:29 +08:00
add_subdirectory(stats)
Revert "[CMake] Provide options for toggling on and off various runtime libraries." This reverts r255170. This change caused a bunch of bot failures and needs to be revised. llvm-svn: 255184
2015-12-10 08:40:58 +08:00
add_subdirectory(lsan)
add_subdirectory(ubsan)
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
foreach(sanitizer ${COMPILER_RT_SANITIZERS_TO_BUILD})
compiler_rt_build_runtime(${sanitizer})
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()
Revert "[CMake] Provide options for toggling on and off various runtime libraries." This reverts r255170. This change caused a bunch of bot failures and needs to be revised. llvm-svn: 255184
2015-12-10 08:40:58 +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)
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
compiler_rt_build_runtime(profile)
[compiler-rt] [XRay] Basic initialization and flag definition for XRay runtime Summary: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Depends on D19904 Reviewers: echristo, kcc, rnk Subscribers: rnk, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D21612 llvm-svn: 276117
2016-07-20 22:14:50 +08:00
endif()
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due to extraneous and missing dependencies and attempts to build on unsupported OSes Summary: This is a fixed-up version of D21612, to address failure identified post-commit. Original commit description: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Fixes include: - Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built - Including <cstddef> to fix std::size_t issue Reviewers: kcc, rnk, echristo Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22611 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
if(COMPILER_RT_BUILD_XRAY)
compiler_rt_build_runtime(xray)
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due to extraneous and missing dependencies and attempts to build on unsupported OSes Summary: This is a fixed-up version of D21612, to address failure identified post-commit. Original commit description: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Fixes include: - Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built - Including <cstddef> to fix std::size_t issue Reviewers: kcc, rnk, echristo Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22611 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
endif()
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
if(COMPILER_RT_BUILD_LIBFUZZER)
compiler_rt_build_runtime(fuzzer)
endif()
scudo: Add support for diagnosing memory errors when memory tagging is enabled. Introduce a function __scudo_get_error_info() that may be called to interpret a crash resulting from a memory error, potentially in another process, given information extracted from the crashing process. The crash may be interpreted as a use-after-free, buffer overflow or buffer underflow. Also introduce a feature to optionally record a stack trace for each allocation and deallocation. If this feature is enabled, a stack trace for the allocation and (if applicable) the deallocation will also be available via __scudo_get_error_info(). Differential Revision: https://reviews.llvm.org/D77283
2020-01-28 10:43:46 +08:00
[MemProf] Decouple memprof build from COMPILER_RT_BUILD_SANITIZERS The MemProf compiler-rt support relies on some of the support only built when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some initial bot failures, and I addressed those by making the memprof runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS (3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b). However, this resulted in another inconsistency with how the tests were set up that was hit by Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1142191 Undo the original bot fix and address this with a more comprehensive fix that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS is disabled, by also building the necessary pieces under COMPILER_RT_BUILD_MEMPROF. Tested by configuring with a similar command as to what was used in the failing Chromium configure. I reproduced the Chromium failure, as well as the original bot failure I tried to fix in 3ed77ecd0a5d5e5c33770f0f9d3d75cf2f80c80b, with that fix reverted. Confirmed it now works. Differential Revision: https://reviews.llvm.org/D90190
2020-10-27 04:36:01 +08:00
if(COMPILER_RT_BUILD_MEMPROF AND COMPILER_RT_HAS_SANITIZER_COMMON)
[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
compiler_rt_build_runtime(memprof)
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_build_runtime(orc)
endif()
scudo: Add support for diagnosing memory errors when memory tagging is enabled. Introduce a function __scudo_get_error_info() that may be called to interpret a crash resulting from a memory error, potentially in another process, given information extracted from the crashing process. The crash may be interpreted as a use-after-free, buffer overflow or buffer underflow. Also introduce a feature to optionally record a stack trace for each allocation and deallocation. If this feature is enabled, a stack trace for the allocation and (if applicable) the deallocation will also be available via __scudo_get_error_info(). Differential Revision: https://reviews.llvm.org/D77283
2020-01-28 10:43:46 +08:00
# It doesn't normally make sense to build runtimes when a sanitizer is enabled,
# so we don't add_subdirectory the runtimes in that case. However, the opposite
# is true for fuzzers that exercise parts of the runtime. So we add the fuzzer
# directories explicitly here.
add_subdirectory(scudo/standalone/fuzz)