mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-16 10:56:31 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/compiler-rt/CMakeLists.txt

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

870 lines
38 KiB
CMake
Raw Permalink 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-04 22:12:04 +00:00
# CMake build for CompilerRT.
#
# An important constraint of the build is that it only produces libraries
# based on the ability of the host toolchain to target various platforms.
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
[compiler-rt] Revise IDE folder structure (#89753) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 09:26:45 +02:00
set(LLVM_SUBPROJECT_TITLE "Compiler-RT")
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
[compiler-rt] Don't redefine LLVM_COMMON_CMAKE_UTILS if it's defined (#66761) If we are building compiler-rt inside llvm-x.y.z.src directory, we should not redefine LLVM_COMMON_CMAKE_UTILS.
2023-10-04 20:05:48 +08:00
if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
endif()
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
NO_POLICY_SCOPE)
Call cmake_minimum_required at the top of CMakeLists.txt Summary: Since r298413, the NEW behavior of the CMake policy CMP0056 is followed. However, it is only effective after the call to cmake_minimum_required. This causes CMAKE_EXE_LINKER_FLAGS etc. to be unused when CMake tries to check compilers for languages specified in the 'project' declaration. Set cmake_minimum_required(VERSION) at the top of the file and ahead of the project declaration. Reviewers: beanz Subscribers: mgorny, srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D34282 llvm-svn: 305593
2017-06-16 21:14:45 +00:00
[compiler-rt] Explicitly enable C extensions for profile (#110555) The profiling code requires GNU extensions as it uses functions such as getpagesize(), fdopen(), etc. The problem manifests when the compiler is built to not default to the extensions mode, e.g. custom config with -std=c2x. CMake didn't support this scenario very well, but it's been fixed by CMP0128. Set the policy to NEW as we now conform to it.
2024-10-14 15:07:11 +03:00
# TODO(CMake 3.22): remove
if(POLICY CMP0128)
cmake_policy(SET CMP0128 NEW)
endif()
Revert "[compiler-rt][cmake] Use HandleOutOfTreeLLVM like libcxx and friends" This reverts commit 8c9f62ea90c70d538766a81ef5980c9223b8566b, which is causing build failures on the bots because it inadvertently changes the output directory of the compiler-rt libs when built as a runtime. Differential Revision: https://reviews.llvm.org/D117815
2022-01-21 12:20:28 -05:00
# Check if compiler-rt is built as a standalone project.
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR COMPILER_RT_STANDALONE_BUILD)
project(CompilerRT C CXX ASM)
set(COMPILER_RT_STANDALONE_BUILD TRUE)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
endif()
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
# Add path for custom compiler-rt modules.
list(INSERT CMAKE_MODULE_PATH 0
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
)
[sanitizers] Sanitizer tests CMake clean up: try #2 This patch addresses two issues: Most of the time, hacks with `if/else` in order to get support for multi-configuration builds are superfluous. The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it expands to `.` on all single-configuration builds, and to a configuration name otherwise. The `if/else` hacks for the library name generation should also not be done, as CMake has `TARGET_FILE` generator expression precisely for this purpose, as it expands to the exact filename of the resulting target. Differential Revision: https://reviews.llvm.org/D35952 llvm-svn: 309341
2017-07-28 00:50:56 +00:00
if(CMAKE_CONFIGURATION_TYPES)
set(CMAKE_CFG_RESOLVED_INTDIR "${CMAKE_CFG_INTDIR}/")
else()
set(CMAKE_CFG_RESOLVED_INTDIR "")
endif()
[CMake] Move the AIX archiver settings to a module This allows their reuse across projects. The name of the module is intentionally generic because we would like to move more platform checks there. Differential Revision: https://reviews.llvm.org/D115276
2021-12-07 11:53:38 -08:00
include(SetPlatformToolchainTools)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
include(base-config-ix)
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
include(CompilerRTUtils)
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
include(CMakeDependentOption)
Get the linker version and pass the it to compiler-rt tests on Darwin. (#86220) The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects the linker version at configure time. The driver uses this information to build the correct set of arguments for the linker. This patch detects the linker version again during compiler-rt configuration and passes it to the tests. This allows a clang built on a machine with a new linker to run compiler-rt tests on a machine with an old linker. rdar://125198603
2024-03-22 15:29:36 -07:00
include(GetDarwinLinkerVersion)
Add top-level CMake 'compiler-rt' target to build all compiler-rt libraries llvm-svn: 191747
2013-10-01 12:52:15 +00:00
[compiler-rt] [test] Fix using toolchains that rely on Clang default configs (#113491) The use of CLANG_NO_DEFAULT_CONFIG in the tests was added because some Linux distributions had a global default config file, that added flags relating to hardening, which interfere with the sanitizer tests. By setting CLANG_NO_DEFAULT_CONFIG, the global default config files that are found are ignored, and the sanitizers get the expected default compiler behaviour. (This was https://github.com/llvm/llvm-project/issues/60394, which was fixed in 8ab762557fb057af1a3015211ee116a975027e78.) However, some toolchains may rely on default config files for mandatory parts required for functioning at all - setting things like sysroots, -rtlib, -unwindlib, -stdlib, -fuse-ld etc. In such a case we can't forcibly disable any default config, because it will break the otherwise working toolchain. Add a test for whether the compiler works while passing --no-default-config to it. If the option is accepted and the toolchain still works while that is set, set CLANG_NO_DEFAULT_CONFIG while running tests. (This adds a little bit of inconsistency, as we're testing for the command line option, while using the environment variable. However doing compile testing with an environment variable isn't quite as easily doable, and passing an extra command line flag to all compile commands while testing, is a bit clumsy - therefore this inconsistency.)
2024-10-24 23:45:14 +03:00
include(CheckCXXCompilerFlag)
# Check if we can compile with --no-default-config, or if that omits a config
# file that is essential for the toolchain to work properly.
#
# Using CMAKE_REQUIRED_FLAGS to make sure the flag is used both for compilation
# and for linking.
#
# Doing this test early on, to see if the flag works on the toolchain
# out of the box. Later on, we end up adding -nostdlib and similar flags
# to all test compiles, which easily can give false positives on this test.
set(OLD_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --no-default-config")
check_cxx_compiler_flag("" COMPILER_RT_HAS_NO_DEFAULT_CONFIG_FLAG)
set(CMAKE_REQUIRED_FLAGS "${OLD_CMAKE_REQUIRED_FLAGS}")
[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-14 19:59:24 +00:00
option(COMPILER_RT_BUILD_BUILTINS "Build builtins" ON)
mark_as_advanced(COMPILER_RT_BUILD_BUILTINS)
[AArch64][compiler-rt] Option to build compiler-rt without FMV support. This commit adds compiler-rt cmake option COMPILER_RT_DISABLE_AARCH64_FMV which, when enabled, doesn't include function multiversioning features initilization code in 'builtins' build. Differential Revision: https://reviews.llvm.org/D141199
2022-12-30 13:34:45 +00:00
option(COMPILER_RT_DISABLE_AARCH64_FMV "Disable AArch64 Function Multi Versioning support" OFF)
mark_as_advanced(COMPILER_RT_DISABLE_AARCH64_FMV)
[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-14 19:59:24 +00:00
option(COMPILER_RT_BUILD_SANITIZERS "Build sanitizers" ON)
mark_as_advanced(COMPILER_RT_BUILD_SANITIZERS)
[compiler-rt][XRay] Default COMPILER_RT_BUILD_XRAY to ON llvm-svn: 277975
2016-08-08 03:58:57 +00:00
option(COMPILER_RT_BUILD_XRAY "Build xray" ON)
[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 07:39:55 +00:00
mark_as_advanced(COMPILER_RT_BUILD_XRAY)
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-21 23:25:50 +00:00
option(COMPILER_RT_BUILD_LIBFUZZER "Build libFuzzer" ON)
mark_as_advanced(COMPILER_RT_BUILD_LIBFUZZER)
[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 05:03:55 +00:00
option(COMPILER_RT_BUILD_PROFILE "Build profile runtime" ON)
mark_as_advanced(COMPILER_RT_BUILD_PROFILE)
Reapply "[compiler-rt][ctx_instr] Add `ctx_profile` component" (#89625) This reverts commit 8b2ba6a144e728ee4116e2804e9b5aed8824e726. The uild errors (see below) were likely due to the same issue PR #88074 fixed. Addressed by following that PR. https://lab.llvm.org/buildbot/#/builders/165/builds/52789 https://lab.llvm.org/buildbot/#/builders/91/builds/25273
2024-04-22 19:30:20 +02:00
option(COMPILER_RT_BUILD_CTX_PROFILE "Build ctx profile runtime" ON)
mark_as_advanced(COMPILER_RT_BUILD_CTX_PROFILE)
[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-03 15:21:20 -07:00
option(COMPILER_RT_BUILD_MEMPROF "Build memory profiling runtime" ON)
mark_as_advanced(COMPILER_RT_BUILD_MEMPROF)
[XRay][compiler-rt] Allow for building the XRay runtime without PREINIT initialization. Summary: Define a build-time configuration option for the XRay runtime to determine whether the archive will add an entry to the `.preinit_array` section of the binary. We also allow for initializing the XRay data structures with an explicit call to __xray_init(). This allows us to give users the capability to initialize the XRay data structures on demand. This can allow us to start porting XRay to platforms where `.preinit_array` isn't a supported section. It also allows us to limit the effects of XRay in the initialization sequence for applications that are sensitive to this kind of interference (i.e. large binaries) or those that want to package XRay control in libraries. Future changes should allow us to build two different library archives for the XRay runtime, and allow clang users to determine which version to link. Reviewers: dblaikie, kpw, pelikan Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D36080 llvm-svn: 309909
2017-08-03 00:58:45 +00:00
option(COMPILER_RT_BUILD_XRAY_NO_PREINIT "Build xray with no preinit patching" OFF)
mark_as_advanced(COMPILER_RT_BUILD_XRAY_NO_PREINIT)
[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-23 21:14:56 -07:00
option(COMPILER_RT_BUILD_ORC "Build ORC runtime" ON)
mark_as_advanced(COMPILER_RT_BUILD_ORC)
[libc] add integration tests for scudo in libc This change adds tests to make sure that SCUDO is being properly included with llvm libc. This change also adds the toggles to properly use SCUDO, as GWP-ASan is enabled by default and must be included for SCUDO to function. Reviewed By: sivachandra, hctim Differential Revision: https://reviews.llvm.org/D106919
2021-07-27 17:44:14 +00:00
option(COMPILER_RT_BUILD_GWP_ASAN "Build GWP-ASan, and link it into SCUDO" ON)
mark_as_advanced(COMPILER_RT_BUILD_GWP_ASAN)
Control-flow Enforcement Technology (CET), published by Intel, introduces indirect branch tracking(IBT) feature aiming to ensure the target address of an indirect jump/call is not tampered. When IBT is enabled, each function or target of any indirect jump/call will start with an 'endbr32/64' instruction otherwise the program will crash during execution. To build an application with CET enabled. we need to ensure: 1. build the source code with "-fcf-protection=full" 2. all the libraries linked with .o files must be CET enabled too This patch aims to enable CET for compiler-rt builtins library, we add an option "COMPILER_RT_ENABLE_CET" whose default value is OFF to enable CET for compiler-rt in building time and when this option is "ON", "-fcf-protection=full" is added to BUILTINS_CFLAG and the "endbr32/64" will be placed in the beginning of each assembly function. We also enabled CET for crtbegin, crtend object files in this patch. Reviewed by: MaskRay, compnerd, manojgupta, efriedma Differential Revision: https://reviews.llvm.org/D109811 Signed-off-by: jinge90 <ge.jin@intel.com>
2022-01-10 09:23:28 +08:00
option(COMPILER_RT_ENABLE_CET "Build Compiler RT with CET enabled" OFF)
[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-14 19:59:24 +00:00
[SCUDO] add cmake options for custom sysroot These options will allow the SCUDO standalone to be built with custom headers. Specifically, this patch will enable building with the LLVM-libc headers. Reviewed By: abrachet Differential Revision: https://reviews.llvm.org/D135702
2022-10-10 15:07:06 -07:00
option(COMPILER_RT_SCUDO_STANDALONE_SYSROOT_PATH "Set custom sysroot for building SCUDO standalone" OFF)
mark_as_advanced(COMPILER_RT_SCUDO_STANDALONE_SYSROOT_PATH)
option(COMPILER_RT_SCUDO_STANDALONE_BUILD_SHARED "Build SCUDO standalone for shared libraries" ON)
mark_as_advanced(COMPILER_RT_SCUDO_STANDALONE_BUILD_SHARED)
option(COMPILER_RT_BUILD_SCUDO_STANDALONE_WITH_LLVM_LIBC "Build SCUDO standalone with LLVM's libc headers" OFF)
mark_as_advanced(COMPILER_RT_BUILD_SCUDO_STANDALONE_WITH_LLVM_LIBC)
[compiler-rt][Fuchsia] Disable interceptors while enabling new/delete replacements This disables use of hwasan interceptors which we do not use on Fuchsia. This explicitly sets the macro for defining the hwasan versions of new/delete. Differential Revision: https://reviews.llvm.org/D103544
2021-06-02 11:33:49 -07:00
if(FUCHSIA)
set(COMPILER_RT_HWASAN_WITH_INTERCEPTORS_DEFAULT OFF)
else()
set(COMPILER_RT_HWASAN_WITH_INTERCEPTORS_DEFAULT ON)
endif()
set(COMPILER_RT_HWASAN_WITH_INTERCEPTORS ${COMPILER_RT_HWASAN_WITH_INTERCEPTORS_DEFAULT} CACHE BOOL "Enable libc interceptors in HWASan (testing mode)")
[hwasan] Add a (almost) no-interceptor mode. Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
2018-08-20 21:49:15 +00:00
[compiler-rt] Fix cmake warnings - Fix cmake BOOL misspellings - Set cmake policy for CMP0075 to NEW As requested by smeenai I've compared CMAkeCache.txt in master with and without this patch and the only changes are to the variable types I fixed: $ diff build-b1-master/CMakeCache.txt build-b1-compiler-rt-fix-cmake-warnings/CMakeCache.txt 503c503 < COMPILER_RT_BAREMETAL_BUILD:STRING=OFF --- > COMPILER_RT_BAREMETAL_BUILD:BOOL=OFF 550c550 < COMPILER_RT_HWASAN_WITH_INTERCEPTORS:STRING=ON --- > COMPILER_RT_HWASAN_WITH_INTERCEPTORS:BOOL=ON Patch by Wink Saville <wink@saville.com>. Differential Revision: https://reviews.llvm.org/D61203 llvm-svn: 361866
2019-05-28 19:09:17 +00:00
set(COMPILER_RT_BAREMETAL_BUILD OFF CACHE BOOL
[cmake] Disable building enable_execute_stack.c for baremetal targets. Disable building enable_execute_stack.c for targets that do not have support for mprotect(). Differential Revision: https://reviews.llvm.org/D33018 llvm-svn: 302680
2017-05-10 15:34:25 +00:00
"Build for a bare-metal target.")
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
if (COMPILER_RT_STANDALONE_BUILD)
[compiler-rt] Build with C++17 explicitly We've started using C++17 constructs in compiler-rt now (e.g. string_view in ORC), but when using the bootstrapping build, we won't inherit the C++ standard from LLVM, and compilation may fail if we default to an older standard. Explicitly build compiler-rt with C++17 in a standalone build, which matches what other subprojects (e.g. Clang and LLD) do.
2022-08-16 16:24:42 -07:00
set(CMAKE_CXX_STANDARD 17 CACHE STRING "C++ standard to conform to")
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)
[CMake][compiler-rt] Don't load LLVM config in the runtimes build LLVM runtimes build already loads the LLVM config and sets all appropriate variables, no need to do it again. Differential Revision: https://reviews.llvm.org/D137870
2022-11-11 22:50:14 +00:00
if (NOT LLVM_RUNTIMES_BUILD)
load_llvm_config()
endif()
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 12:56:34 +00:00
if (TARGET intrinsics_gen)
# Loading the llvm config causes this target to be imported so place it
# under the appropriate folder in an IDE.
[compiler-rt] Revise IDE folder structure (#89753) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 09:26:45 +02:00
set_target_properties(intrinsics_gen PROPERTIES FOLDER "LLVM/Tablegenning")
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 12:56:34 +00:00
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 10:04:29 +00:00
[CMake] Remove dead FindPythonInterp code LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D87189
2020-09-05 17:52:23 +03:00
find_package(Python3 COMPONENTS Interpreter)
if(NOT Python3_Interpreter_FOUND)
message(WARNING "Python3 not found, using python2 as a fallback")
find_package(Python2 COMPONENTS Interpreter REQUIRED)
if(Python2_VERSION VERSION_LESS 2.7)
message(SEND_ERROR "Python 2.7 or newer is required")
build: use Python3 for compiler-rt compiler-rt is built in a unified configuration on some of the builders which requires that this is updated to follow the same pattern as LLVM.
2020-04-28 17:25:23 +00:00
endif()
[CMake] Remove dead FindPythonInterp code LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D87189
2020-09-05 17:52:23 +03:00
# Treat python2 as python3
build: use Python3 for compiler-rt compiler-rt is built in a unified configuration on some of the builders which requires that this is updated to follow the same pattern as LLVM.
2020-04-28 17:25:23 +00:00
add_executable(Python3::Interpreter IMPORTED)
set_target_properties(Python3::Interpreter PROPERTIES
[CMake] Remove dead FindPythonInterp code LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D87189
2020-09-05 17:52:23 +03:00
IMPORTED_LOCATION ${Python2_EXECUTABLE})
set(Python3_EXECUTABLE ${Python2_EXECUTABLE})
[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 10:04:29 +00:00
endif()
build: fix standalone builds for compiler-rt on Darwin When building static fat libraries, we need to ensure that we use libtool rather than llvm-ar to create the library. Duplicate the rules from LLVM to ensure that we correctly build the fat libraries when building compiler-rt standalone. This also requires that we duplicate the workaround for the `DYLD_LIBRARY_PATH` for SIP. Additionally, ensure that we set the `CMAKE_*_ARCHIVE_FINISH` variable to ensure that we do not try to use `ranlib` on that target. llvm-svn: 342425
2018-09-17 23:25:36 +00:00
# Ensure that fat libraries are built correctly on Darwin
[runtimes] Use llvm-libtool-darwin for runtimes build It's full featured now and we can use it for the runtimes build instead of relying on an external libtool, which means the CMAKE_HOST_APPLE restriction serves no purpose either now. Restrict llvm-lipo to Darwin targets while I'm here, since it's only needed there. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D86367
2020-08-21 13:03:13 -07:00
if(APPLE)
[builtins] Use libtool for builtins when building for Apple platform compiler-rt already uses libtool instead of ar when building for Apple platform, but that's not being used when builtins are being built separately e.g. as part of the runtimes build. This change extracts the logic setting up libtool into a separate file and uses it from both the compiler-rt and standalone builtins build. Differential Revision: https://reviews.llvm.org/D62820 llvm-svn: 362466
2019-06-04 02:38:15 +00:00
include(UseLibtool)
build: fix standalone builds for compiler-rt on Darwin When building static fat libraries, we need to ensure that we use libtool rather than llvm-ar to create the library. Duplicate the rules from LLVM to ensure that we correctly build the fat libraries when building compiler-rt standalone. This also requires that we duplicate the workaround for the `DYLD_LIBRARY_PATH` for SIP. Additionally, ensure that we set the `CMAKE_*_ARCHIVE_FINISH` variable to ensure that we do not try to use `ranlib` on that target. llvm-svn: 342425
2018-09-17 23:25:36 +00:00
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 10:04:29 +00:00
# Define default arguments to lit.
set(LIT_ARGS_DEFAULT "-sv")
if (MSVC OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
set(LLVM_LIT_OUTPUT_DIR "${COMPILER_RT_EXEC_OUTPUT_DIR}")
[CMake] Rudimentary support for standalone CompilerRT build system. This change allows to build compiler-rt libraries separately from LLVM/Clang (path to LLVM build directory should be specified at configure time). Running tests is not yet supported. llvm-svn: 201647
2014-02-19 07:49:16 +00:00
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
construct_compiler_rt_default_triple()
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-14 18:01:19 +00:00
if ("${COMPILER_RT_DEFAULT_TARGET_TRIPLE}" MATCHES ".*hf$")
Ensure that armhf builtins library is created when using an hf abi Reviewers: beanz, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D38045 llvm-svn: 313650
2017-09-19 17:54:11 +00:00
if (${COMPILER_RT_DEFAULT_TARGET_ARCH} MATCHES "^arm")
set(COMPILER_RT_DEFAULT_TARGET_ARCH "armhf")
[sanitizer] Disable fast_unwind_on_malloc as default for arm-linux-gnu ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1] and fast-unwider is also unreliable when mixing arm and thumb code [2]. The fast unwinder on ARM tries to probe and compare the frame-pointer at different stack layout positions and it works reliable only on systems where all the libraries were built in arm mode (either with gcc or clang) or with clang in thmb mode (which uses the same stack frame pointer layout in arm and thumb). However when mixing objects built with different abi modes the fast unwinder is still problematic as shown by the failures on the AddressSanitizer.ThreadStackReuseTest. For these failures, the malloc is called by the loader itself and since it has been built with a thum enabled gcc, the stack frame is not correctly obtained and the suppression rule is not applied (resulting in a leak warning). The check for fast-unwinder-works is also changed: instead of checking f it is explicit enabled in the compiler flags, it now checks if compiler defined thumb pre-processor. This should fix BZ#44158. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172 [2] https://bugs.llvm.org/show_bug.cgi?id=44158 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D88958
2020-10-12 14:23:26 -03:00
CHECK_SYMBOL_EXISTS (__thumb__ "" COMPILER_RT_ARM_THUMB)
Ensure that armhf builtins library is created when using an hf abi Reviewers: beanz, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D38045 llvm-svn: 313650
2017-09-19 17:54:11 +00:00
endif()
endif()
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-14 18:01:19 +00:00
if ("${COMPILER_RT_DEFAULT_TARGET_TRIPLE}" MATCHES ".*android.*")
[CMake] Check for androidabi in CMakeLists.txt not base-config-ix.cmake COMPILER_RT_DEFAULT_TARGET_ABI is not set in base-config-ix.cmake, so we need to move this check into CMakeLists.txt. llvm-svn: 273957
2016-06-27 22:52:05 +00:00
set(ANDROID 1)
[sanitizer] Fix Android API level parsing on arm
2020-11-14 01:52:44 -08:00
string(REGEX MATCH "-target(=| +)[^ ]+android[a-z]*([0-9]+)" ANDROID_API_LEVEL "${CMAKE_C_FLAGS}")
[sanitizer] Get Android API from --target Depends on D90792. Differential Revision: https://reviews.llvm.org/D90793
2020-11-04 13:10:17 -08:00
set(ANDROID_API_LEVEL ${CMAKE_MATCH_2})
[CMake] Check for androidabi in CMakeLists.txt not base-config-ix.cmake COMPILER_RT_DEFAULT_TARGET_ABI is not set in base-config-ix.cmake, so we need to move this check into CMakeLists.txt. llvm-svn: 273957
2016-06-27 22:52:05 +00:00
endif()
[sanitizer] Move android_commoands from asan into sanitizer_common llvm-svn: 313443
2017-09-16 05:13:56 +00:00
pythonize_bool(ANDROID)
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 12:33:39 +00:00
set(COMPILER_RT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
[ASan] lit tests: create common autogenerated config for running compiler-rt lit tests, and use it in ASan llvm-svn: 183400
2013-06-06 12:35:48 +00:00
set(COMPILER_RT_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 12:33:39 +00:00
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
pythonize_bool(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
Revert "Revert "[compiler-rt] Fix check for cross-compiling"" This reverts commit 18f6b05e0a5a4197bac787f5522669576c134869. This is a reland of https://reviews.llvm.org/D132130 which I incorrectly thought had broken the builds. Differential Revision: https://reviews.llvm.org/D132230
2022-08-19 06:46:22 -07:00
# We support running instrumented tests when we're not cross-compiling
Enable sanitizer tests (check-sanitizer, check-asan) on Windows llvm-svn: 208701
2014-05-13 14:25:49 +00:00
# and target a UNIX-like system or Windows.
# We can run tests on Android even when we are cross-compiling.
[compiler-rt] Fix cross-compiling detection Previously the detection compares "CMAKE_SYSTEM_NAME" and "CMAKE_TARGET_SYSTEM_NAME", which only contains OS names like "Linux". This is not sufficient when cross-compiling for different target CPUs. This patch uses CMAKE_CROSSCOMPILING, which sets automatically by CMake when cross compiling. Reviewed By: smeenai, phosek Differential Revision: https://reviews.llvm.org/D147103
2023-03-30 12:47:33 +08:00
if((NOT "${CMAKE_CROSSCOMPILING}" AND (UNIX OR WIN32))
Revert "Revert "[compiler-rt] Fix check for cross-compiling"" This reverts commit 18f6b05e0a5a4197bac787f5522669576c134869. This is a reland of https://reviews.llvm.org/D132130 which I incorrectly thought had broken the builds. Differential Revision: https://reviews.llvm.org/D132230
2022-08-19 06:46:22 -07:00
OR ANDROID OR COMPILER_RT_EMULATOR)
Change the cmake variable COMPILER_RT_CAN_EXECUTE_TESTS to be an option so that it can overwritten. The reason why this simple change is needed is that I am trying to set up a quick cmake/ninja based buildbot and apple-clang does not support using the sanitizers currently. The default behavior follows exactly what was there before implying that no ones builds should be affected at all. llvm-svn: 178455
2013-04-01 04:13:03 +00:00
option(COMPILER_RT_CAN_EXECUTE_TESTS "Can we execute instrumented tests" ON)
Define COMPILER_RT_CAN_EXECUTE_TESTS variable on platforms where we can produce working binaries and use it in build rules for sanitizers tests llvm-svn: 171160
2012-12-27 13:19:23 +00:00
else()
Change the cmake variable COMPILER_RT_CAN_EXECUTE_TESTS to be an option so that it can overwritten. The reason why this simple change is needed is that I am trying to set up a quick cmake/ninja based buildbot and apple-clang does not support using the sanitizers currently. The default behavior follows exactly what was there before implying that no ones builds should be affected at all. llvm-svn: 178455
2013-04-01 04:13:03 +00:00
option(COMPILER_RT_CAN_EXECUTE_TESTS "Can we execute instrumented tests" OFF)
Define COMPILER_RT_CAN_EXECUTE_TESTS variable on platforms where we can produce working binaries and use it in build rules for sanitizers tests llvm-svn: 171160
2012-12-27 13:19:23 +00:00
endif()
Change the cmake variable COMPILER_RT_CAN_EXECUTE_TESTS to be an option so that it can overwritten. The reason why this simple change is needed is that I am trying to set up a quick cmake/ninja based buildbot and apple-clang does not support using the sanitizers currently. The default behavior follows exactly what was there before implying that no ones builds should be affected at all. llvm-svn: 178455
2013-04-01 04:13:03 +00:00
Add a CMake option COMPILER_RT_DEBUG for building runtimes with full debug info. Differential Revision: http://llvm-reviews.chandlerc.com/D1984 llvm-svn: 193449
2013-10-25 23:03:34 +00:00
option(COMPILER_RT_DEBUG "Build runtimes with full debug info" OFF)
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-03 20:08:22 +00:00
option(COMPILER_RT_EXTERNALIZE_DEBUGINFO
"Generate dSYM files and strip executables and libraries (Darwin Only)" OFF)
Add a CMake option COMPILER_RT_DEBUG for building runtimes with full debug info. Differential Revision: http://llvm-reviews.chandlerc.com/D1984 llvm-svn: 193449
2013-10-25 23:03:34 +00:00
# COMPILER_RT_DEBUG_PYBOOL is used by lit.common.configured.in.
pythonize_bool(COMPILER_RT_DEBUG)
[tsan] Support interception of libdispatch on Linux This is a new attempt for bringing TSan libdispatch support to Linux. The main issue with the last patch (https://reviews.llvm.org/D53171) was that we want to avoid building a separate library. The updated plan is as follows: 1) Hide libdispatch support behind a flag: true on Darwin, false elsewhere. If flag is specified, assume that libdispatch header and -flbocks is available for building. This way we can directly include the libdispatch header and rely on blocks runtime for our implementation. 2) Optionally/weakly intercept libdispatch API functions. This patch accomplishes 1). It compiles (without the flag enabled) on Linux. Follow-up patches will provide 2) and enabling of tests on Linux. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D58935 llvm-svn: 355538
2019-03-06 19:25:09 +00:00
option(COMPILER_RT_INTERCEPT_LIBDISPATCH
[TSan][libdispatch] Enable linking and running of tests on Linux When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library now has a dependency on the blocks runtime and libdispatch. Make sure we set all the required linking options. Also add cmake options for specifying additional library paths to instruct the linker where to search for libdispatch and the blocks runtime. This allows us to build TSan runtime with libdispatch support without installing those libraries into default linker library paths. `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid aborting the build due to failing the link step in CMake's check_c_compiler test. Reviewed By: dvyukov, kubamracek Differential Revision: https://reviews.llvm.org/D59334 llvm-svn: 356281
2019-03-15 17:52:27 +00:00
"Support interception of libdispatch (GCD). Requires '-fblocks'" OFF)
[TSan][libdispatch] Specify libdispatch header dir for lit tests Specify libdispatch header dir (include path) for lit tests. This is the last missing piece in order to run the libdispatch tests on Linux even when libdispatch is installed in a custom path instead of a default (system) location. llvm-svn: 357707
2019-04-04 17:25:43 +00:00
option(COMPILER_RT_LIBDISPATCH_INSTALL_PATH
"Specify if libdispatch is installed in a custom location" "")
[TSan][libdispatch] We don't require any setup on Darwin llvm-svn: 357519
2019-04-02 20:04:32 +00:00
if (COMPILER_RT_INTERCEPT_LIBDISPATCH AND NOT APPLE)
[NFC][TSan][libdispatch] Better CMake variable names llvm-svn: 357664
2019-04-04 01:10:07 +00:00
set(COMPILER_RT_LIBDISPATCH_CFLAGS -fblocks)
set(COMPILER_RT_TEST_LIBDISPATCH_CFLAGS)
[TSan][libdispatch] Specify libdispatch header dir for lit tests Specify libdispatch header dir (include path) for lit tests. This is the last missing piece in order to run the libdispatch tests on Linux even when libdispatch is installed in a custom path instead of a default (system) location. llvm-svn: 357707
2019-04-04 17:25:43 +00:00
if (COMPILER_RT_LIBDISPATCH_INSTALL_PATH)
[NFC][TSan][libdispatch] Better CMake variable names llvm-svn: 357664
2019-04-04 01:10:07 +00:00
list(APPEND COMPILER_RT_TEST_LIBDISPATCH_CFLAGS
[NFC][TSan][libdispatch] Tiny CMake file cleanup llvm-svn: 360453
2019-05-10 18:37:30 +00:00
-I${COMPILER_RT_LIBDISPATCH_INSTALL_PATH}/include
[TSan][libdispatch] Specify libdispatch header dir for lit tests Specify libdispatch header dir (include path) for lit tests. This is the last missing piece in order to run the libdispatch tests on Linux even when libdispatch is installed in a custom path instead of a default (system) location. llvm-svn: 357707
2019-04-04 17:25:43 +00:00
-L${COMPILER_RT_LIBDISPATCH_INSTALL_PATH}/lib
-Wl,-rpath=${COMPILER_RT_LIBDISPATCH_INSTALL_PATH}/lib)
[TSan][libdispatch] Enable linking and running of tests on Linux When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library now has a dependency on the blocks runtime and libdispatch. Make sure we set all the required linking options. Also add cmake options for specifying additional library paths to instruct the linker where to search for libdispatch and the blocks runtime. This allows us to build TSan runtime with libdispatch support without installing those libraries into default linker library paths. `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid aborting the build due to failing the link step in CMake's check_c_compiler test. Reviewed By: dvyukov, kubamracek Differential Revision: https://reviews.llvm.org/D59334 llvm-svn: 356281
2019-03-15 17:52:27 +00:00
endif()
[NFC][TSan][libdispatch] Better CMake variable names llvm-svn: 357664
2019-04-04 01:10:07 +00:00
list(APPEND COMPILER_RT_TEST_LIBDISPATCH_CFLAGS -lBlocksRuntime -ldispatch)
[TSan][libdispatch] Enable linking and running of tests on Linux When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library now has a dependency on the blocks runtime and libdispatch. Make sure we set all the required linking options. Also add cmake options for specifying additional library paths to instruct the linker where to search for libdispatch and the blocks runtime. This allows us to build TSan runtime with libdispatch support without installing those libraries into default linker library paths. `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid aborting the build due to failing the link step in CMake's check_c_compiler test. Reviewed By: dvyukov, kubamracek Differential Revision: https://reviews.llvm.org/D59334 llvm-svn: 356281
2019-03-15 17:52:27 +00:00
endif()
[tsan] Support interception of libdispatch on Linux This is a new attempt for bringing TSan libdispatch support to Linux. The main issue with the last patch (https://reviews.llvm.org/D53171) was that we want to avoid building a separate library. The updated plan is as follows: 1) Hide libdispatch support behind a flag: true on Darwin, false elsewhere. If flag is specified, assume that libdispatch header and -flbocks is available for building. This way we can directly include the libdispatch header and rely on blocks runtime for our implementation. 2) Optionally/weakly intercept libdispatch API functions. This patch accomplishes 1). It compiles (without the flag enabled) on Linux. Follow-up patches will provide 2) and enabling of tests on Linux. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D58935 llvm-svn: 355538
2019-03-06 19:25:09 +00:00
if (APPLE) # Always enable on Apple platforms.
set(COMPILER_RT_INTERCEPT_LIBDISPATCH ON)
endif()
[Sanitizer] Add 'dispatch' feature to be used in compiler-rt tests Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D59037 llvm-svn: 355617
2019-03-07 18:15:23 +00:00
pythonize_bool(COMPILER_RT_INTERCEPT_LIBDISPATCH)
[tsan] Support interception of libdispatch on Linux This is a new attempt for bringing TSan libdispatch support to Linux. The main issue with the last patch (https://reviews.llvm.org/D53171) was that we want to avoid building a separate library. The updated plan is as follows: 1) Hide libdispatch support behind a flag: true on Darwin, false elsewhere. If flag is specified, assume that libdispatch header and -flbocks is available for building. This way we can directly include the libdispatch header and rely on blocks runtime for our implementation. 2) Optionally/weakly intercept libdispatch API functions. This patch accomplishes 1). It compiles (without the flag enabled) on Linux. Follow-up patches will provide 2) and enabling of tests on Linux. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D58935 llvm-svn: 355538
2019-03-06 19:25:09 +00:00
Make sure SANITIZER_MIN_OSX_VERSION is defined before using it. llvm-svn: 307448
2017-07-07 22:40:13 +00:00
if(APPLE AND SANITIZER_MIN_OSX_VERSION AND SANITIZER_MIN_OSX_VERSION VERSION_LESS "10.9")
[compiler-rt] Make cxxabi availability configurable in cmake Summary: Allow for use of cxxabi to be disabled from cmake. This will make sanitizers usable when c++ abi is unavailable. Reviewers: pcc, rnk, samsonov, beanz, compnerd Subscribers: llvm-commits, compnerd, dberris Differential Revision: https://reviews.llvm.org/D23639 llvm-svn: 279451
2016-08-22 18:31:37 +00:00
# Mac OS X prior to 10.9 had problems with exporting symbols from
# libc++/libc++abi.
ubsan: Unbreak ubsan_cxx runtime library on Windows. This was originally broken by r258744 which introduced a weak reference from ubsan to ubsan_cxx. This reference does not work directly on Windows because COFF has no direct concept of weak symbols. The fix is to use /alternatename to create a weak external reference to ubsan_cxx. Also fix the definition (and the name, so that we drop cached values) of the cmake flag that controls whether to build ubsan_cxx. Now the user-controllable flag is always on, and we turn it off internally depending on whether we support building it. Differential Revision: https://reviews.llvm.org/D37882 llvm-svn: 313391
2017-09-15 20:24:12 +00:00
set(cxxabi_supported OFF)
[compiler-rt] Make cxxabi availability configurable in cmake Summary: Allow for use of cxxabi to be disabled from cmake. This will make sanitizers usable when c++ abi is unavailable. Reviewers: pcc, rnk, samsonov, beanz, compnerd Subscribers: llvm-commits, compnerd, dberris Differential Revision: https://reviews.llvm.org/D23639 llvm-svn: 279451
2016-08-22 18:31:37 +00:00
else()
ubsan: Unbreak ubsan_cxx runtime library on Windows. This was originally broken by r258744 which introduced a weak reference from ubsan to ubsan_cxx. This reference does not work directly on Windows because COFF has no direct concept of weak symbols. The fix is to use /alternatename to create a weak external reference to ubsan_cxx. Also fix the definition (and the name, so that we drop cached values) of the cmake flag that controls whether to build ubsan_cxx. Now the user-controllable flag is always on, and we turn it off internally depending on whether we support building it. Differential Revision: https://reviews.llvm.org/D37882 llvm-svn: 313391
2017-09-15 20:24:12 +00:00
set(cxxabi_supported ON)
[compiler-rt] Make cxxabi availability configurable in cmake Summary: Allow for use of cxxabi to be disabled from cmake. This will make sanitizers usable when c++ abi is unavailable. Reviewers: pcc, rnk, samsonov, beanz, compnerd Subscribers: llvm-commits, compnerd, dberris Differential Revision: https://reviews.llvm.org/D23639 llvm-svn: 279451
2016-08-22 18:31:37 +00:00
endif()
Revert r332683 & r332684 relating to compiler runtime checks r332683 passes flags to the compiler without first checking if they are supported. llvm-svn: 332754
2018-05-18 18:44:37 +00:00
option(SANITIZER_ALLOW_CXXABI "Allow use of C++ ABI details in ubsan" ON)
ubsan: Unbreak ubsan_cxx runtime library on Windows. This was originally broken by r258744 which introduced a weak reference from ubsan to ubsan_cxx. This reference does not work directly on Windows because COFF has no direct concept of weak symbols. The fix is to use /alternatename to create a weak external reference to ubsan_cxx. Also fix the definition (and the name, so that we drop cached values) of the cmake flag that controls whether to build ubsan_cxx. Now the user-controllable flag is always on, and we turn it off internally depending on whether we support building it. Differential Revision: https://reviews.llvm.org/D37882 llvm-svn: 313391
2017-09-15 20:24:12 +00:00
fix typo in a CMake SANITIZER_CAN_USE_CXXABI variable initial definition The current variable name isn't used anywhere else, which indicates it's a typo. Let's fix it before someone copy+pastes it somewhere else. Reviewed By: Jim Differential Revision: https://reviews.llvm.org/D39157
2021-04-12 14:04:38 +08:00
set(SANITIZER_CAN_USE_CXXABI OFF)
ubsan: Unbreak ubsan_cxx runtime library on Windows. This was originally broken by r258744 which introduced a weak reference from ubsan to ubsan_cxx. This reference does not work directly on Windows because COFF has no direct concept of weak symbols. The fix is to use /alternatename to create a weak external reference to ubsan_cxx. Also fix the definition (and the name, so that we drop cached values) of the cmake flag that controls whether to build ubsan_cxx. Now the user-controllable flag is always on, and we turn it off internally depending on whether we support building it. Differential Revision: https://reviews.llvm.org/D37882 llvm-svn: 313391
2017-09-15 20:24:12 +00:00
if (cxxabi_supported AND SANITIZER_ALLOW_CXXABI)
set(SANITIZER_CAN_USE_CXXABI ON)
endif()
[compiler-rt] Make cxxabi availability configurable in cmake Summary: Allow for use of cxxabi to be disabled from cmake. This will make sanitizers usable when c++ abi is unavailable. Reviewers: pcc, rnk, samsonov, beanz, compnerd Subscribers: llvm-commits, compnerd, dberris Differential Revision: https://reviews.llvm.org/D23639 llvm-svn: 279451
2016-08-22 18:31:37 +00:00
pythonize_bool(SANITIZER_CAN_USE_CXXABI)
[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 08:34:26 +00:00
macro(handle_default_cxx_lib var)
[CMake] Avoid accidental C++ standard library dependency in sanitizers While sanitizers don't use C++ standard library, we could still end up accidentally including or linking it just by the virtue of using the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these accidental dependencies. Reviewed By: smeenai, vitalybuka Differential Revision: https://reviews.llvm.org/D88922
2020-10-30 20:19:39 -07:00
# Specifying -stdlib= in CMAKE_CXX_FLAGS overrides the defaults.
if (CMAKE_CXX_FLAGS MATCHES "-stdlib=([a-zA-Z+]*)")
set(${var}_LIBNAME "${CMAKE_MATCH_1}")
set(${var}_SYSTEM 1)
elseif (${var} STREQUAL "default")
[compiler-rt] Set the default C++ library to libc++ on OpenBSD (#107694)
2024-12-19 18:33:29 -05:00
if (APPLE OR CMAKE_SYSTEM_NAME MATCHES "FreeBSD" OR CMAKE_SYSTEM_NAME MATCHES "OpenBSD")
[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 08:34:26 +00:00
set(${var}_LIBNAME "libc++")
set(${var}_SYSTEM 1)
Revert "[compiler-rt] Improve defaults for Android" This reverts commit cf403c10fba72ddc6a083a0e1603974d0749c6b3. This is breaking Android sanitizer buildbots (see the discussion on https://reviews.llvm.org/D158793).
2023-08-29 10:37:49 -07:00
elseif (FUCHSIA)
[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 08:34:26 +00:00
set(${var}_LIBNAME "libc++")
set(${var}_INTREE 1)
else()
set(${var}_LIBNAME "libstdc++")
set(${var}_SYSTEM 1)
endif()
else()
set(${var}_LIBNAME "${${var}}")
set(${var}_SYSTEM 1)
endif()
endmacro()
# This is either directly the C++ ABI library or the full C++ library
# which pulls in the ABI transitively.
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
# TODO: Mark this as internal flag, most users should use COMPILER_RT_CXX_LIBRARY.
Support libc++abi in addition to libstdc++ This change adds sanitizer support for LLVM's libunwind and libc++abi as an alternative to libstdc++. This allows using the in tree version of libunwind and libc++abi which is useful when building a toolchain for different target. Differential Revision: https://reviews.llvm.org/D34501 llvm-svn: 309362
2017-07-28 03:39:39 +00:00
set(SANITIZER_CXX_ABI "default" CACHE STRING
"Specify C++ ABI library to use.")
[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 08:34:26 +00:00
set(CXXABIS none default libstdc++ libc++ libcxxabi)
Support libc++abi in addition to libstdc++ This change adds sanitizer support for LLVM's libunwind and libc++abi as an alternative to libstdc++. This allows using the in tree version of libunwind and libc++abi which is useful when building a toolchain for different target. Differential Revision: https://reviews.llvm.org/D34501 llvm-svn: 309362
2017-07-28 03:39:39 +00:00
set_property(CACHE SANITIZER_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
[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 08:34:26 +00:00
handle_default_cxx_lib(SANITIZER_CXX_ABI)
Support libc++abi in addition to libstdc++ This change adds sanitizer support for LLVM's libunwind and libc++abi as an alternative to libstdc++. This allows using the in tree version of libunwind and libc++abi which is useful when building a toolchain for different target. Differential Revision: https://reviews.llvm.org/D34501 llvm-svn: 309362
2017-07-28 03:39:39 +00: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 08:34:26 +00:00
# This needs to be a full C++ library for linking gtest and unit tests.
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
# TODO: Mark this as internal flag, most users should use COMPILER_RT_CXX_LIBRARY.
[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 08:34:26 +00:00
set(SANITIZER_TEST_CXX "default" CACHE STRING
"Specify C++ library to use for tests.")
set(CXXLIBS none default libstdc++ libc++)
set_property(CACHE SANITIZER_TEST_CXX PROPERTY STRINGS ;${CXXLIBS})
handle_default_cxx_lib(SANITIZER_TEST_CXX)
Support libc++abi in addition to libstdc++ This change adds sanitizer support for LLVM's libunwind and libc++abi as an alternative to libstdc++. This allows using the in tree version of libunwind and libc++abi which is useful when building a toolchain for different target. Differential Revision: https://reviews.llvm.org/D34501 llvm-svn: 309362
2017-07-28 03:39:39 +00:00
Revert "[compiler-rt] Improve defaults for Android" This reverts commit cf403c10fba72ddc6a083a0e1603974d0749c6b3. This is breaking Android sanitizer buildbots (see the discussion on https://reviews.llvm.org/D158793).
2023-08-29 10:37:49 -07:00
option(COMPILER_RT_USE_LLVM_UNWINDER "Use the LLVM unwinder." OFF)
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
cmake_dependent_option(COMPILER_RT_ENABLE_STATIC_UNWINDER
"Statically link the LLVM unwinder." OFF
"COMPILER_RT_USE_LLVM_UNWINDER" OFF)
[CMake][compiler-rt] Enable statically linking unwinder and c++abi Rather than guessing whether to use static or shared version of unwinder and c++abi when using linking against the in-tree versions, provide a CMake option to control this. Differential Revision: https://reviews.llvm.org/D57492 llvm-svn: 352723
2019-01-31 03:38:43 +00:00
set(DEFAULT_SANITIZER_USE_STATIC_LLVM_UNWINDER OFF)
Revert "[compiler-rt] Improve defaults for Android" This reverts commit cf403c10fba72ddc6a083a0e1603974d0749c6b3. This is breaking Android sanitizer buildbots (see the discussion on https://reviews.llvm.org/D158793).
2023-08-29 10:37:49 -07:00
if (FUCHSIA)
[CMake][compiler-rt] Enable statically linking unwinder and c++abi Rather than guessing whether to use static or shared version of unwinder and c++abi when using linking against the in-tree versions, provide a CMake option to control this. Differential Revision: https://reviews.llvm.org/D57492 llvm-svn: 352723
2019-01-31 03:38:43 +00:00
set(DEFAULT_SANITIZER_USE_STATIC_LLVM_UNWINDER ON)
elseif (DEFINED LIBUNWIND_ENABLE_SHARED AND NOT LIBUNWIND_ENABLE_SHARED)
set(DEFAULT_SANITIZER_USE_STATIC_LLVM_UNWINDER ON)
endif()
option(SANITIZER_USE_STATIC_LLVM_UNWINDER
"Use static LLVM unwinder." ${DEFAULT_SANITIZER_USE_STATIC_LLVM_UNWINDER})
[compiler-rt][test] Add shared_unwind requirement When using a static libunwind, the check_memcpy.c can fail because it checks that tsan intercepted all memcpy/memmoves in the final binary. Though if the static libunwind is not instrumented, then this will fail because it may contain regular memcpy/memmoves. This adds a new REQUIRES check for ensuring that this test won't run unless a dynamic libunwind.so is provided. Differential Revision: https://reviews.llvm.org/D111194
2021-10-06 11:09:29 -07:00
pythonize_bool(SANITIZER_USE_STATIC_LLVM_UNWINDER)
[CMake][compiler-rt] Enable statically linking unwinder and c++abi Rather than guessing whether to use static or shared version of unwinder and c++abi when using linking against the in-tree versions, provide a CMake option to control this. Differential Revision: https://reviews.llvm.org/D57492 llvm-svn: 352723
2019-01-31 03:38:43 +00:00
set(DEFAULT_SANITIZER_USE_STATIC_CXX_ABI OFF)
if (DEFINED LIBCXXABI_ENABLE_SHARED AND NOT LIBCXXABI_ENABLE_SHARED)
set(DEFAULT_SANITIZER_USE_STATIC_CXX_ABI ON)
endif()
option(SANITIZER_USE_STATIC_CXX_ABI
"Use static libc++abi." ${DEFAULT_SANITIZER_USE_STATIC_CXX_ABI})
[compiler-rt][test] Add REQUIRES for checking static libc++abi intercept-rethrow-exception.cc fails when running runtimes tests if linking in a hermetic libc++abi. This is because if libc++abi is used, then asan expects to intercept __cxa_rethrow_primary_exception on linux, which should unpoison the stack. If we statically link in libc++abi though, it will contain a strong definition for __cxa_rethrow_primary_exception which wins over the weakly defined interceptor provided by asan, causing the test to fail by not unpoisoning the stack on the exception being thrown. It's likely no one has encountered this before and possible that upstream tests opt for dynamically linking where the interceptor can work properly. An ideal long term solution would be to update the interceptor and libc++[abi] APIs to work for this case, but that will likely take a long time to work out. In the meantime, since the test isn't necessarily broken, we can just add another REQUIRES check to make sure that it's only run if we aren't statically linking in libc++abi. Differential Revision: https://reviews.llvm.org/D109938
2021-09-22 15:25:05 -07:00
pythonize_bool(SANITIZER_USE_STATIC_CXX_ABI)
[CMake][compiler-rt] Enable statically linking unwinder and c++abi Rather than guessing whether to use static or shared version of unwinder and c++abi when using linking against the in-tree versions, provide a CMake option to control this. Differential Revision: https://reviews.llvm.org/D57492 llvm-svn: 352723
2019-01-31 03:38:43 +00:00
[CMake] Handle in-tree libc++ for sanitizer tests We have been relying on the logic for C++ ABI library for sanitizer tests but that's incorrect since most tests require a full C++ library and not just C++ ABI. This change tries to address this by using the dependency on libc++ if available. Differential Revision: https://reviews.llvm.org/D118163
2022-01-25 09:42:28 -08:00
set(DEFAULT_SANITIZER_USE_STATIC_TEST_CXX OFF)
if (DEFINED LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_SHARED)
set(DEFAULT_SANITIZER_USE_STATIC_TEST_CXX ON)
endif()
option(SANITIZER_USE_STATIC_TEST_CXX
"Use static libc++ for tests." ${DEFAULT_SANITIZER_USE_STATIC_TEST_CXX})
pythonize_bool(SANITIZER_USE_STATIC_TEST_CXX)
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
set(COMPILER_RT_SUPPORTED_CXX_LIBRARIES none default libcxx)
set(COMPILER_RT_CXX_LIBRARY "default" CACHE STRING "Specify C++ library to use. Supported values are ${COMPILER_RT_SUPPORTED_CXX_LIBRARIES}.")
if (NOT "${COMPILER_RT_CXX_LIBRARY}" IN_LIST COMPILER_RT_SUPPORTED_CXX_LIBRARIES)
message(FATAL_ERROR "Unsupported C++ library: '${COMPILER_RT_CXX_LIBRARY}'. Supported values are ${COMPILER_RT_SUPPORTED_CXX_LIBRARIES}.")
endif()
cmake_dependent_option(COMPILER_RT_STATIC_CXX_LIBRARY
"Statically link the C++ library." OFF
"COMPILER_RT_CXX_LIBRARY" OFF)
[CMake] Change the flag to use compiler-rt builtins to boolean This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 llvm-svn: 337116
2018-07-15 03:05:20 +00:00
set(DEFAULT_COMPILER_RT_USE_BUILTINS_LIBRARY OFF)
Revert "[compiler-rt] Improve defaults for Android" This reverts commit cf403c10fba72ddc6a083a0e1603974d0749c6b3. This is breaking Android sanitizer buildbots (see the discussion on https://reviews.llvm.org/D158793).
2023-08-29 10:37:49 -07:00
if (FUCHSIA)
[CMake] Change the flag to use compiler-rt builtins to boolean This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 llvm-svn: 337116
2018-07-15 03:05:20 +00:00
set(DEFAULT_COMPILER_RT_USE_BUILTINS_LIBRARY ON)
[CMake] Support builtins as Clang default rtlib in compiler-rt Use compiler-rt builtins when selected as default Clang rtlib and avoid explicitly passing -rtlib= flag to avoid the "argument unused during compilation" warning. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47115 llvm-svn: 333037
2018-05-22 22:58:48 +00:00
endif()
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 03:39:38 +00:00
[CMake] Change the flag to use compiler-rt builtins to boolean This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 llvm-svn: 337116
2018-07-15 03:05:20 +00:00
option(COMPILER_RT_USE_BUILTINS_LIBRARY
"Use compiler-rt builtins instead of libgcc" ${DEFAULT_COMPILER_RT_USE_BUILTINS_LIBRARY})
[CMake][compiler-rt] Support for using compiler-rt atomic library (#106603) Not every toolchain provides and want to use libatomic which is a part of GCC, some toolchains may opt into using compiler-rt atomic library.
2024-09-03 10:28:49 -07:00
option(COMPILER_RT_USE_ATOMIC_LIBRARY "Use compiler-rt atomic instead of libatomic" OFF)
[CMake] Support libc++ as Clang default stdlib in compiler-rt Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
2018-05-22 18:33:27 +00:00
include(config-ix)
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
#================================
# Setup Compiler Flags
#================================
builtins: avoid duplicating unwind declarations Use unwind.h to get the declarations for unwinding interfaces. This header is already provided by clang and gcc, so this adds no additional dependencies for building the builtins library. It avoids the duplication which may drift over time though. llvm-svn: 225990
2015-01-14 15:55:17 +00:00
Control-flow Enforcement Technology (CET), published by Intel, introduces indirect branch tracking(IBT) feature aiming to ensure the target address of an indirect jump/call is not tampered. When IBT is enabled, each function or target of any indirect jump/call will start with an 'endbr32/64' instruction otherwise the program will crash during execution. To build an application with CET enabled. we need to ensure: 1. build the source code with "-fcf-protection=full" 2. all the libraries linked with .o files must be CET enabled too This patch aims to enable CET for compiler-rt builtins library, we add an option "COMPILER_RT_ENABLE_CET" whose default value is OFF to enable CET for compiler-rt in building time and when this option is "ON", "-fcf-protection=full" is added to BUILTINS_CFLAG and the "endbr32/64" will be placed in the beginning of each assembly function. We also enabled CET for crtbegin, crtend object files in this patch. Reviewed by: MaskRay, compnerd, manojgupta, efriedma Differential Revision: https://reviews.llvm.org/D109811 Signed-off-by: jinge90 <ge.jin@intel.com>
2022-01-10 09:23:28 +08:00
# fcf-protection is a gcc/clang option for CET support on Linux platforms.
# We need to handle MSVC CET option on Windows platforms.
if (NOT MSVC)
if (COMPILER_RT_ENABLE_CET AND NOT COMPILER_RT_HAS_FCF_PROTECTION_FLAG)
message(FATAL_ERROR "Compiler used to build compiler-rt doesn't support CET!")
endif()
endif()
[CMake] Use /W3 instead of -Wall on Windows. Remove add_definitions abuse. llvm-svn: 203786
2014-03-13 11:31:10 +00:00
if(MSVC)
Fix some warnings in the MSVC build - Fixes warnings about the ignored -fms-compatibility-version flag. - Fixes warnings about overriding /W4 with /W3 and back. - Fixes a warning where PREFETCH() expanded to nothing in a braceless if block. llvm-svn: 273021
2016-06-17 17:48:52 +00:00
# Override any existing /W flags with /W4. This is what LLVM does. Failing to
# remove other /W[0-4] flags will result in a warning about overriding a
# previous flag.
if (COMPILER_RT_HAS_W4_FLAG)
string(REGEX REPLACE " /W[0-4]" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
string(REGEX REPLACE " /W[0-4]" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
append_string_if(COMPILER_RT_HAS_W4_FLAG /W4 CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
[CMake] Use /W3 instead of -Wall on Windows. Remove add_definitions abuse. llvm-svn: 203786
2014-03-13 11:31:10 +00:00
else()
append_string_if(COMPILER_RT_HAS_WALL_FLAG -Wall CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
[CMake] Introduce COMPILER_RT_ENABLE_WERROR option llvm-svn: 202021
2014-02-24 11:22:39 +00:00
if(COMPILER_RT_ENABLE_WERROR)
[CMake] Use /W3 instead of -Wall on Windows. Remove add_definitions abuse. llvm-svn: 203786
2014-03-13 11:31:10 +00:00
append_string_if(COMPILER_RT_HAS_WERROR_FLAG -Werror CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append_string_if(COMPILER_RT_HAS_WX_FLAG /WX CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[CMake] Introduce COMPILER_RT_ENABLE_WERROR option llvm-svn: 202021
2014-02-24 11:22:39 +00:00
endif()
Append -D__func__=__FUNCTION__ to SANITIZER_COMMON_CFLAGS This way it gets picked up for all sanitizer libs, both sanitizer_common and asan. I believe those are the only libs that build with asan. There should be no need to set the __func__ definition inside clang_compile. llvm-svn: 202303
2014-02-26 21:54:39 +00:00
# Emulate C99 and C++11's __func__ for MSVC prior to 2013 CTP.
Move COMPILER_RT_HAS_FUNC check from r202303 to config-ix.cmake llvm-svn: 202353
2014-02-27 06:52:41 +00:00
if(NOT COMPILER_RT_HAS_FUNC_SYMBOL)
Add accidentally removed -D llvm-svn: 202355
2014-02-27 07:03:32 +00:00
add_definitions(-D__func__=__FUNCTION__)
Append -D__func__=__FUNCTION__ to SANITIZER_COMMON_CFLAGS This way it gets picked up for all sanitizer libs, both sanitizer_common and asan. I believe those are the only libs that build with asan. There should be no need to set the __func__ definition inside clang_compile. llvm-svn: 202303
2014-02-26 21:54:39 +00:00
endif()
[sanitizer] Android ELF TLS is supported from Q (API 29) Reviewed By: oontvoo, MaskRay Differential Revision: https://reviews.llvm.org/D103214
2021-05-27 14:53:49 -07:00
# Provide some common commandline flags for Sanitizer runtimes.
if("${ANDROID_API_LEVEL}" GREATER_EQUAL 29)
Disable emulated-tls for compiler-rt+tests on Android if ELF_TLS is presence. This is necessary for enabling LSAN on Android (D89251) because: - LSAN will have false negatives if run with emulated-tls. - Bionic ELF-TLS is not compatible with Gold (hence the need for LLD) Differential Revision: https://reviews.llvm.org/D89615
2020-10-17 01:57:02 -04:00
list(APPEND SANITIZER_COMMON_CFLAGS -fno-emulated-tls)
[sanitizer] Fix -fno-emulated-tls setup COMPILER_RT_TEST_COMPILER_CFLAGS is a string
2020-11-04 19:22:28 -08:00
string(APPEND COMPILER_RT_TEST_COMPILER_CFLAGS " -fno-emulated-tls")
Disable emulated-tls for compiler-rt+tests on Android if ELF_TLS is presence. This is necessary for enabling LSAN on Android (D89251) because: - LSAN will have false negatives if run with emulated-tls. - Bionic ELF-TLS is not compatible with Gold (hence the need for LLD) Differential Revision: https://reviews.llvm.org/D89615
2020-10-17 01:57:02 -04:00
endif()
[compiler-rt] Don't use -fPIC when building for Windows Summary: This flag doesn't make sense on Windows systems. Reviewers: beanz, kubabrecka, compnerd Subscribers: dberris, llvm-commits, beanz Differential Revision: https://reviews.llvm.org/D24320 llvm-svn: 280953
2016-09-08 15:57:22 +00:00
if(NOT WIN32)
append_list_if(COMPILER_RT_HAS_FPIC_FLAG -fPIC SANITIZER_COMMON_CFLAGS)
endif()
[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-15 22:47:54 +00:00
append_list_if(COMPILER_RT_HAS_FNO_BUILTIN_FLAG -fno-builtin SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG -fno-exceptions SANITIZER_COMMON_CFLAGS)
[sanitizers] Avoid using -fomit-frame-pointer on Darwin On Darwin, we're having multiple issues with using -fomit-frame-pointer in the AddressSanitizer and ThreadSanitizer runtimes, so we're actually not using -fomit-frame-pointer in the our builds of the sanitizer dylibs. This patch just pushes our internal change upstream. The issues are usually with debuggers, profilers and other tools that unwind the stack (crash reporter), which are often simply not able to get a stack trace. And crashlogs that don't contain a stack trace are a huge problem. Differential Revision: https://reviews.llvm.org/D31376 llvm-svn: 298859
2017-03-27 17:14:48 +00:00
if(NOT COMPILER_RT_DEBUG AND NOT APPLE)
[sanitizer] Don't use -fomit-frame-pointer in COMPILER_RT_DEBUG=On builds Using -fomit-frame-pointer sometimes makes a crash log miss some frames. Let's not use this optimization in debug builds. Differential Revision: http://reviews.llvm.org/D20425 llvm-svn: 270376
2016-05-22 19:59:06 +00:00
append_list_if(COMPILER_RT_HAS_FOMIT_FRAME_POINTER_FLAG -fomit-frame-pointer SANITIZER_COMMON_CFLAGS)
endif()
[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-15 22:47:54 +00:00
append_list_if(COMPILER_RT_HAS_FUNWIND_TABLES_FLAG -funwind-tables SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_FNO_STACK_PROTECTOR_FLAG -fno-stack-protector SANITIZER_COMMON_CFLAGS)
Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library This patch adds runtime support for the Safe Stack protection to compiler-rt (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of compiler-rt. The patch adds basic runtime support for the safe stack to compiler-rt that manages unsafe stack allocation/deallocation for each thread. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6096 llvm-svn: 239763
2015-06-15 21:08:47 +00:00
append_list_if(COMPILER_RT_HAS_FNO_SANITIZE_SAFE_STACK_FLAG -fno-sanitize=safe-stack SANITIZER_COMMON_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-15 22:47:54 +00:00
append_list_if(COMPILER_RT_HAS_FVISIBILITY_HIDDEN_FLAG -fvisibility=hidden SANITIZER_COMMON_CFLAGS)
[compiler-rt] Avoid unnecessarily hiding inline visibility [NFC] Summary: having fvisibility=hidden obviates the need for fvisibility-inlines-hidden. Reviewers: cryptoad, weimingz, mgorny, vsk, compnerd, peter.smith, nikhgupt Reviewed By: vsk, nikhgupt Subscribers: dberris, mgorny Differential Revision: https://reviews.llvm.org/D40269 llvm-svn: 319257
2017-11-28 23:41:42 +00:00
if(NOT COMPILER_RT_HAS_FVISIBILITY_HIDDEN_FLAG)
append_list_if(COMPILER_RT_HAS_FVISIBILITY_INLINES_HIDDEN_FLAG -fvisibility-inlines-hidden SANITIZER_COMMON_CFLAGS)
endif()
[sanitizer] Restore -fno-lto accidentally removed in r226169. llvm-svn: 226177
2015-01-15 16:31:22 +00:00
append_list_if(COMPILER_RT_HAS_FNO_LTO_FLAG -fno-lto SANITIZER_COMMON_CFLAGS)
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-09 15:25:41 -07:00
# By default do not instrument or use profdata for compiler-rt.
if(NOT COMPILER_RT_ENABLE_PGO)
if(LLVM_PROFDATA_FILE AND COMPILER_RT_HAS_FNO_PROFILE_INSTR_USE_FLAG)
list(APPEND SANITIZER_COMMON_CFLAGS "-fno-profile-instr-use")
endif()
if(LLVM_BUILD_INSTRUMENTED MATCHES IR AND COMPILER_RT_HAS_FNO_PROFILE_GENERATE_FLAG)
list(APPEND SANITIZER_COMMON_CFLAGS "-fno-profile-generate")
[cmake] By default do not instrument compiler-rt if LLVM_BUILD_INSTRUMENTED_COVERAGE is ON Applying the same rules as for LLVM_BUILD_INSTRUMENTED build in the cmake files. By having this patch, we are able to disable/enable instrument+coverage build of the compiler-rt project when building instrumented LLVM. Differential Revision: https://reviews.llvm.org/D108127
2021-11-09 10:55:34 +01:00
elseif((LLVM_BUILD_INSTRUMENTED OR LLVM_BUILD_INSTRUMENTED_COVERAGE) AND COMPILER_RT_HAS_FNO_PROFILE_INSTR_GENERATE_FLAG)
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-09 15:25:41 -07:00
list(APPEND SANITIZER_COMMON_CFLAGS "-fno-profile-instr-generate")
[cmake] By default do not instrument compiler-rt if LLVM_BUILD_INSTRUMENTED_COVERAGE is ON Applying the same rules as for LLVM_BUILD_INSTRUMENTED build in the cmake files. By having this patch, we are able to disable/enable instrument+coverage build of the compiler-rt project when building instrumented LLVM. Differential Revision: https://reviews.llvm.org/D108127
2021-11-09 10:55:34 +01:00
if(LLVM_BUILD_INSTRUMENTED_COVERAGE AND COMPILER_RT_HAS_FNO_COVERAGE_MAPPING_FLAG)
list(APPEND SANITIZER_COMMON_CFLAGS "-fno-coverage-mapping")
endif()
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-09 15:25:41 -07:00
endif()
endif()
[sanitizer] Re-enable -fno-function-sections for powerpc64le Summary: For a reason that hasn't been investigated for lack of powerpc knowledge and hardware, -fno-function-sections is required for the Sanitizers to work properly on powerpc64le. Without, the function-sections-are-bad test fails on that architecture (and that architecture only). This patch re-enables the flag in the powerpc64le cflags. I have to admit I am not entirely sure if my way is the proper way to do this, so if anyone has a better way, I'll be happy to oblige. Reviewers: kcc, eugenis Reviewed By: eugenis Subscribers: nemanjai, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29285 llvm-svn: 293558
2017-01-30 22:31:49 +00:00
# The following is a workaround for powerpc64le. This is the only architecture
# that requires -fno-function-sections to work properly. If lacking, the ASan
compiler-rt: Rename cc files below test/asan to cpp See r367803 and similar other changes. llvm-svn: 367887
2019-08-05 16:48:12 +00:00
# Linux test function-sections-are-bad.cpp fails with the following error:
[sanitizer] Re-enable -fno-function-sections for powerpc64le Summary: For a reason that hasn't been investigated for lack of powerpc knowledge and hardware, -fno-function-sections is required for the Sanitizers to work properly on powerpc64le. Without, the function-sections-are-bad test fails on that architecture (and that architecture only). This patch re-enables the flag in the powerpc64le cflags. I have to admit I am not entirely sure if my way is the proper way to do this, so if anyone has a better way, I'll be happy to oblige. Reviewers: kcc, eugenis Reviewed By: eugenis Subscribers: nemanjai, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29285 llvm-svn: 293558
2017-01-30 22:31:49 +00:00
# 'undefined symbol: __sanitizer_unaligned_load32'.
if(DEFINED TARGET_powerpc64le_CFLAGS)
[CMake] Enable -qfuncsect when building with IBM XL Summary: The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`. The comment about sanitizers and `-f[no-]function-sections` is corrected also, as it is pertinent to this patch. The sanitizer-related use of `-fno-function-sections` is associated with powerpc64le, a target for which there is an IBM XL compiler, so that use is updated in this patch to apply `-qnofuncsect` in case a build using the XL compiler is viable on that platform. This patch has been verified with the XL compiler on AIX only. Reviewers: daltenty, stevewan Reviewed By: daltenty Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D72335
2020-01-15 10:42:12 -05:00
if(CMAKE_CXX_COMPILER_ID MATCHES "XL")
append("-qnofuncsect" TARGET_powerpc64le_CFLAGS)
else()
append_list_if(COMPILER_RT_HAS_FNO_FUNCTION_SECTIONS_FLAG -fno-function-sections TARGET_powerpc64le_CFLAGS)
endif()
[sanitizer] Re-enable -fno-function-sections for powerpc64le Summary: For a reason that hasn't been investigated for lack of powerpc knowledge and hardware, -fno-function-sections is required for the Sanitizers to work properly on powerpc64le. Without, the function-sections-are-bad test fails on that architecture (and that architecture only). This patch re-enables the flag in the powerpc64le cflags. I have to admit I am not entirely sure if my way is the proper way to do this, so if anyone has a better way, I'll be happy to oblige. Reviewers: kcc, eugenis Reviewed By: eugenis Subscribers: nemanjai, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29285 llvm-svn: 293558
2017-01-30 22:31:49 +00:00
endif()
[compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining Since updating the SystemZ LLVM build bot system to Ubuntu 18.04, all bots are red due to two ASAN failures. It turns out these are triggered due to building the ASAN support libraries, in particular the interceptor routines using GCC 7. Specifically, at least on our platform, this compiler decides to "partially inline" some of those interceptors, creating intermediate stub routines like "__interceptor_recvfrom.part.321". These will show up in the backtraces at interception points, causing testsuite failures. As a workaround to get the build bots green again, this patch adds the -fno-partial-inlining command line option when building the common sanitizer support libraries on s390x, if that option is supported by the compiler. llvm-svn: 363679
2019-06-18 13:26:27 +00:00
# The following is a workaround for s390x. This avoids creation of "partial
# inline" function fragments when building the asan libraries with certain
# GCC versions. The presence of those fragments, in particular for the
# interceptors, changes backtraces seen in asan error cases, which causes
# testsuite failures.
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "s390x")
append_list_if(COMPILER_RT_HAS_FNO_PARTIAL_INLINING_FLAG -fno-partial-inlining SANITIZER_COMMON_CFLAGS)
endif()
[CMake] Fix PR18987: discard /MD flag if we're adding /MT llvm-svn: 202472
2014-02-28 08:04:30 +00:00
if(MSVC)
Reland [asan][windows] Eliminate the static asan runtime on windows (#107899) This reapplies 8fa66c6ca7272268747835a0e86805307b62399c ([asan][windows] Eliminate the static asan runtime on windows) for a second time. That PR bounced off the tests because it caused failures in the other sanitizer runtimes, these have been fixed by only building interception, sanitizer_common, and asan with /MD, and continuing to build the rest of the runtimes with /MT. This does mean that any usage of the static ubsan/fuzzer/etc runtimes will mean you're mixing different runtime library linkages in the same app, the interception, sanitizer_common, and asan runtimes are designed for this, however it does result in some linker warnings. Additionally, it turns out when building in release-mode with LLVM_ENABLE_PDBs the build system forced /OPT:ICF. This totally breaks asan's "new" method of doing "weak" functions on windows, and so /OPT:NOICF was explicitly added to asan's link flags. --------- Co-authored-by: Amy Wishnousky <amyw@microsoft.com>
2024-09-09 13:41:08 -07:00
Revert "[asan][windows] Eliminate the static asan runtime on windows (#93770)" This reverts commit 8fa66c6ca7272268747835a0e86805307b62399c.
2024-05-30 11:41:44 -07:00
set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
[compiler-rt] Reinstate removal of CRT choice flags from CMAKE_*_FLAGS* (#67935) This reverts one part of commit 9f4dfcb795bb0ecf9944553f49371164801cd83f, with a modified comment added about the code. Ideally, this would only be reinstated temporarily - but given the situation in vcpkg, it looks likely that they would keep passing the duplicate options for quite some time. The conflicting CRT choice usually are benign but only would cause warnings about one option overriding the other, if passing e.g. "/MDd /MT". However when vcpkg currently sets these options in CMAKE_*_FLAGS_DEBUG, it passes the redundant option /D_DEBUG; thus the compiler finally ends up with e.g. "/D_DEBUG /MDd /MT", which has the effect of defining _DEBUG while using a release mode CRT, which allegedly breaks the build. There's a PR up for removing this redundant /D_DEBUG option in vcpkg in https://github.com/microsoft/vcpkg/pull/34123. With that in place, this change wouldn't be strictly needed.
2023-10-02 13:22:23 +03:00
# Remove any /M[DT][d] flags, and strip any definitions of _DEBUG.
# Since we're using CMAKE_MSVC_RUNTIME_LIBRARY (CMP0091 set to NEW),
# these options shouldn't be included in these flags variables. However,
# package managers that don't know which mechanism is used for passing
# CRT choice flags might be passing them both ways - which leads to
# duplicate CRT choice options. Thus make sure to strip out these flags
# from these variables, when we're forcing a CRT choice other than what
# the user requested here.
foreach(flag_var
CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
string(REGEX REPLACE "[/-]M[DT]d" "" ${flag_var} "${${flag_var}}")
string(REGEX REPLACE "[/-]MD" "" ${flag_var} "${${flag_var}}")
string(REGEX REPLACE "[/-]D_DEBUG" "" ${flag_var} "${${flag_var}}")
endforeach()
[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-15 22:47:54 +00:00
append_list_if(COMPILER_RT_HAS_Oy_FLAG /Oy- SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_GS_FLAG /GS- SANITIZER_COMMON_CFLAGS)
Remove cmake checks for MSVC 1900 / VS 2013 Our minimum Visual C++ version is 19.10 from Visual Studio 2017. llvm-svn: 367362
2019-07-30 22:49:11 +00:00
# Disable thread safe initialization for static locals. ASan shouldn't need
# it. Thread safe initialization assumes that the CRT has already been
# initialized, but ASan initializes before the CRT.
list(APPEND SANITIZER_COMMON_CFLAGS /Zc:threadSafeInit-)
[CMake] Fix PR18987: discard /MD flag if we're adding /MT llvm-svn: 202472
2014-02-28 08:04:30 +00:00
endif()
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
Use -DSANITIZER_DEBUG=1 if COMPILER_RT_DEBUG=ON, now that PR22083 is fixed. llvm-svn: 225293
2015-01-06 20:25:34 +00:00
append_list_if(COMPILER_RT_DEBUG -DSANITIZER_DEBUG=1 SANITIZER_COMMON_CFLAGS)
Remove TSAN_DEBUG in favor of SANITIZER_DEBUG. llvm-svn: 225111
2015-01-03 04:29:12 +00:00
[NFC][sanitizers] Add COMPILER_RT_HAS_WTHREAD_SAFETY_*_FLAG
2023-01-18 17:24:10 -08:00
append_list_if(COMPILER_RT_HAS_WTHREAD_SAFETY_FLAG -Wthread-safety THREAD_SAFETY_FLAGS)
append_list_if(COMPILER_RT_HAS_WTHREAD_SAFETY_REFERENCE_FLAG -Wthread-safety-reference THREAD_SAFETY_FLAGS)
append_list_if(COMPILER_RT_HAS_WTHREAD_SAFETY_BETA_FLAG -Wthread-safety-beta THREAD_SAFETY_FLAGS)
list(APPEND SANITIZER_COMMON_CFLAGS ${THREAD_SAFETY_FLAGS})
string(REPLACE ";" " " thread_safety_flags_space_sep "${THREAD_SAFETY_FLAGS}")
string(APPEND COMPILER_RT_TEST_COMPILER_CFLAGS " ${thread_safety_flags_space_sep}")
sanitizer_common: add thread safety annotations Enable clang Thread Safety Analysis for sanitizers: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html Thread Safety Analysis can detect inconsistent locking, deadlocks and data races. Without GUARDED_BY annotations it has limited value. But this does all the heavy lifting to enable analysis and allows to add GUARDED_BY incrementally. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D105716
2021-07-09 19:29:41 +02:00
[compiler-rt] [CMake] Build compiler-rt with no optimizations if the flag says so Differential Revision: https://reviews.llvm.org/D35400 llvm-svn: 308072
2017-07-15 00:30:46 +00:00
# If we're using MSVC,
[CMake] More fixes for Windows build llvm-svn: 203798
2014-03-13 13:37:07 +00:00
# always respect the optimization flags set by CMAKE_BUILD_TYPE instead.
[compiler-rt] [CMake] Build compiler-rt with no optimizations if the flag says so Differential Revision: https://reviews.llvm.org/D35400 llvm-svn: 308072
2017-07-15 00:30:46 +00:00
if (NOT MSVC)
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
# Build with optimization, unless we're in debug mode.
[compiler-rt] [CMake] Build compiler-rt with no optimizations if the flag says so Differential Revision: https://reviews.llvm.org/D35400 llvm-svn: 308072
2017-07-15 00:30:46 +00:00
if(COMPILER_RT_DEBUG)
Revert "Reland "[compiler-rt][test] Heed COMPILER_RT_DEBUG when compiling unittests"" This reverts commit 255c3e3dcb06299aa2365f70817322a8a381c351, which breaks Msan-x86_64-Test.
2022-12-13 16:38:12 -08:00
list(APPEND SANITIZER_COMMON_CFLAGS -O1)
[compiler-rt] [CMake] Build compiler-rt with no optimizations if the flag says so Differential Revision: https://reviews.llvm.org/D35400 llvm-svn: 308072
2017-07-15 00:30:46 +00:00
else()
list(APPEND SANITIZER_COMMON_CFLAGS -O3)
endif()
[Sanitizer] Build all sanitizer runtime libraries with debug info (with -gline-tables-only, if it's available) llvm-svn: 167584
2012-11-08 14:49:28 +00:00
endif()
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
Remove TSAN_DEBUG in favor of SANITIZER_DEBUG. llvm-svn: 225111
2015-01-03 04:29:12 +00:00
# Determine if we should restrict stack frame sizes.
[Sanitizer] Disable -Wframe-larger-than on SystemZ SystemZ builds show -Wframe-larger-than warnings in two functions: 'sanitizer::SuspendedThreadsListLinux::GetRegistersAndSP' 'sanitizer::SizeClassAllocator32<__sanitizer::AP32>::PopulateFreeList' In both cases, the frame size looks correct; each of the functions has a large local variable that brings the frame size close to the limit even on x86, and the extra 160 bytes of the default register save areas on SystemZ pushes it over the limit. PowerPC and MIPS already disable this warning; do the same on SystemZ. Differential Revision: https://reviews.llvm.org/D66021 llvm-svn: 369543
2019-08-21 15:53:08 +00:00
# Stack frames on PowerPC, Mips, SystemZ and in debug build can be much larger than
Remove TSAN_DEBUG in favor of SANITIZER_DEBUG. llvm-svn: 225111
2015-01-03 04:29:12 +00:00
# anticipated.
# FIXME: Fix all sanitizers and add -Wframe-larger-than to
# SANITIZER_COMMON_FLAGS
if(COMPILER_RT_HAS_WFRAME_LARGER_THAN_FLAG AND NOT COMPILER_RT_DEBUG
[Sanitizer] Disable -Wframe-larger-than on SystemZ SystemZ builds show -Wframe-larger-than warnings in two functions: 'sanitizer::SuspendedThreadsListLinux::GetRegistersAndSP' 'sanitizer::SizeClassAllocator32<__sanitizer::AP32>::PopulateFreeList' In both cases, the frame size looks correct; each of the functions has a large local variable that brings the frame size close to the limit even on x86, and the extra 160 bytes of the default register save areas on SystemZ pushes it over the limit. PowerPC and MIPS already disable this warning; do the same on SystemZ. Differential Revision: https://reviews.llvm.org/D66021 llvm-svn: 369543
2019-08-21 15:53:08 +00:00
AND NOT ${COMPILER_RT_DEFAULT_TARGET_ARCH} MATCHES "powerpc|mips|s390x")
Remove TSAN_DEBUG in favor of SANITIZER_DEBUG. llvm-svn: 225111
2015-01-03 04:29:12 +00:00
set(SANITIZER_LIMIT_FRAME_SIZE TRUE)
else()
set(SANITIZER_LIMIT_FRAME_SIZE FALSE)
endif()
[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-09 21:24:06 +00:00
if(FUCHSIA OR UNIX)
set(SANITIZER_USE_SYMBOLS TRUE)
else()
set(SANITIZER_USE_SYMBOLS FALSE)
endif()
Get the linker version and pass the it to compiler-rt tests on Darwin. (#86220) The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects the linker version at configure time. The driver uses this information to build the correct set of arguments for the linker. This patch detects the linker version again during compiler-rt configuration and passes it to the tests. This allows a clang built on a machine with a new linker to run compiler-rt tests on a machine with an old linker. rdar://125198603
2024-03-22 15:29:36 -07:00
# Get the linker version while configuring compiler-rt and explicitly pass it
# in cflags during testing. This fixes the compiler/linker version mismatch
# issue when running a clang built with a newer Xcode in an older Xcode
set(COMPILER_RT_DARWIN_LINKER_VERSION)
if (APPLE AND NOT CMAKE_LINKER MATCHES ".*lld.*")
get_darwin_linker_version(COMPILER_RT_DARWIN_LINKER_VERSION)
message(STATUS "Host linker version: ${COMPILER_RT_DARWIN_LINKER_VERSION}")
endif()
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
# Build sanitizer runtimes with debug info.
Enable full debug info in the ASan runtime on Windows Clang-cl supports the -gline-tables-only flag, so we were going down that path. Honestly, we should just go ahead and enable full codeview support. llvm-svn: 330989
2018-04-26 20:34:19 +00:00
if(MSVC)
[winasan] Try to fix LNK4099 warnings seen by users /Zi creates a separate PDB that we're supposed to pass along with our sanitizer libraries, but the object library compilation rules aren't set up to handle that. Rather than set that up, put the debug info in the object files the way every other platform does it with /Z7. llvm-svn: 277406
2016-08-02 01:02:46 +00:00
# Use /Z7 instead of /Zi for the asan runtime. This avoids the LNK4099
# warning from the MS linker complaining that it can't find the 'vc140.pdb'
# file used by our object library compilations.
list(APPEND SANITIZER_COMMON_CFLAGS /Z7)
[CMake] Don't use llvm_replace_compiler_option Building compiler-rt standalone outside of the main llvm tree is supported, and in this case, the llvm cmake modules are unavailable. (And even if they are available, it requires including LLVMProcessSources.cmake, which currently isn't included.) This fixes building compiler-rt standalone with MSVC/clang-cl. Differential Revision: https://reviews.llvm.org/D58767 llvm-svn: 355237
2019-03-01 22:30:17 +00:00
foreach(var_to_update
CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO)
string(REGEX REPLACE "(^| )/Z[i7I]($| )" " /Z7 "
"${var_to_update}" "${${var_to_update}}")
endforeach()
[Compiler-RT] On Apple Platforms switch to always emitting full debug info Previously the build used `-gline-tables-only` when `COMPILER_RT_DEBUG` was off (default) and `-g` when `COMPILER_RT_DEBUG` was on. The end result of this meant that the release build of the Sanitizer runtimes were difficult to debug (e.g. information about variables and function arguments were missing). Presumably the reason for preferring `-gline-tables-only` for release builds was to save space. However, for Apple platforms this doesn't matter because debug info lives in separate `.dSYM` files (which aren't shipped) rather than in the shipped `.dylib` files. Now on Apple platforms we always emit full debug info if the compiler supports it and we emit a fatal error if `-g` isn't supported. rdar://79223184 Differential Revision: https://reviews.llvm.org/D107501
2021-08-04 14:29:32 -07:00
elseif(APPLE)
# On Apple platforms use full debug info (i.e. not `-gline-tables-only`)
# for all build types so that the runtime can be debugged.
if(NOT COMPILER_RT_HAS_G_FLAG)
message(FATAL_ERROR "-g is not supported by host compiler")
endif()
list(APPEND SANITIZER_COMMON_CFLAGS -g)
Enable full debug info in the ASan runtime on Windows Clang-cl supports the -gline-tables-only flag, so we were going down that path. Honestly, we should just go ahead and enable full codeview support. llvm-svn: 330989
2018-04-26 20:34:19 +00:00
elseif(COMPILER_RT_HAS_GLINE_TABLES_ONLY_FLAG AND NOT COMPILER_RT_DEBUG)
list(APPEND SANITIZER_COMMON_CFLAGS -gline-tables-only)
elseif(COMPILER_RT_HAS_G_FLAG)
list(APPEND SANITIZER_COMMON_CFLAGS -g)
[Sanitizer] Compile sanitizer runtimes with -Wno-non-virtual-dtor. Virtual dtors may be a problem for us, as sanitizer runtime should not generally assume libstdc++ presence. llvm-svn: 177860
2013-03-25 10:31:49 +00:00
endif()
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
[compiler-rt] Exclude compiler-rt from using -fmodules when LLVM_ENABLE_MODULES=On Sanitizers are intentionally not including system headers and often declare slightly different function prototypes, which is incompatible with -fmodules and -fcxx-modules. Let’s simply exclude compiler-rt from using -fmodules. Differential Revision: https://reviews.llvm.org/D25230 llvm-svn: 283658
2016-10-08 09:01:27 +00:00
if(LLVM_ENABLE_MODULES)
# Sanitizers cannot be built with -fmodules. The interceptors intentionally
# don't include system headers, which is incompatible with modules.
list(APPEND SANITIZER_COMMON_CFLAGS -fno-modules)
endif()
[CMake] Simplify code for detecting/setting compiler flags llvm-svn: 201543
2014-02-18 07:26:58 +00:00
# Turn off several warnings.
[CMake] Detect if -Wfoo is supported instead of -Wno-foo, as GCC occasionally silently discards unknown -Wno-foo flags. llvm-svn: 221925
2014-11-13 21:19:53 +00:00
append_list_if(COMPILER_RT_HAS_WGNU_FLAG -Wno-gnu SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_WVARIADIC_MACROS_FLAG -Wno-variadic-macros SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_WC99_EXTENSIONS_FLAG -Wno-c99-extensions SANITIZER_COMMON_CFLAGS)
sanitizer_common: prepare for enabling format string checking The __attribute__((format)) was added somewhere in 2012, the lost during refactoring, then re-added in 2014 but to te source files, which is a no-op. Move it back to header files so that it actually takes effect. But over the past 7 years we've accumulated whole lot of format string bugs of different types, so disable the warning with -Wno-format for now for incremental clean up. Among the bugs that it warns about are all kinds of bad things: - wrong sizes of arguments - missing/excessive arguments - printing wrong things (e.g. *ptr instead of ptr) - completely messed up format strings - security issues where external string is used as format Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107977
2021-08-12 19:37:29 +02:00
# format-pedantic warns about passing T* for %p, which is not useful.
Disabling some MSVC warnings that are of questionable value. Note, these are disabled by default in LLVM as well, so there is precedence. C4146: 'unary minus operator applied to unsigned type, result still unsigned' C4291: ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception' C4800: ''type' : forcing value to bool 'true' or 'false' (performance warning)' llvm-svn: 220507
2014-10-23 20:39:58 +00:00
append_list_if(COMPILER_RT_HAS_WD4146_FLAG /wd4146 SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_WD4291_FLAG /wd4291 SANITIZER_COMMON_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-15 22:47:54 +00:00
append_list_if(COMPILER_RT_HAS_WD4391_FLAG /wd4391 SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_WD4722_FLAG /wd4722 SANITIZER_COMMON_CFLAGS)
Disabling some MSVC warnings that are of questionable value. Note, these are disabled by default in LLVM as well, so there is precedence. C4146: 'unary minus operator applied to unsigned type, result still unsigned' C4291: ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception' C4800: ''type' : forcing value to bool 'true' or 'false' (performance warning)' llvm-svn: 220507
2014-10-23 20:39:58 +00:00
append_list_if(COMPILER_RT_HAS_WD4800_FLAG /wd4800 SANITIZER_COMMON_CFLAGS)
Some flag cleanup for the sanitizer runtimes. This hoists most of the CFLAGS into a common variable. It also adds detection for -Wno-c99-extensions and uses it to silence a pile of warnings. Finally, it switches to the proper flag -rdynamic. With this, the cmake build is warning free on my bootstrap Linux build. llvm-svn: 162809
2012-08-29 00:13:11 +00:00
[CMake] [MinGW] Build address sanitizer for MinGW if building with clang Differential Revision: https://reviews.llvm.org/D51885 llvm-svn: 343074
2018-09-26 06:53:01 +00:00
append_list_if(MINGW -fms-extensions SANITIZER_COMMON_CFLAGS)
[compiler-rt] Add opt-in -ftrivial-auto-var-init flag for writing over uninitialized stack variiables This might allow lsan to find more leaks that would have gone undetected. When lsan searches for leaked pointers on the stack, if a leaked pointer that was pushed to the stack in a prior function call would not be scrubbed on a future function call, then the scan will see the pointer on the stack and not mark it as leaked. Such holes can exist in the lsan runtime where there may be uninitialized data. Adding auto-var-init can scrub some of that data and might be able to catch more leaks that would've gone undetected this way. See https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=111351 for more details. Differential Revision: https://reviews.llvm.org/D135716
2022-12-08 19:29:28 +00:00
# When lsan scans the stack for detecting reachable pointers, it's possible for
# a leaked pointer, which was pushed to the stack on an earlier function call,
# to still exist on the stack when doing a leak check if that part of the stack
# was not overwritten. In particular, if there's any uninitialized data in the
# lsan runtime, and the SP we start from is sufficiently deep into the runtime,
# then a leaked pointer could be marked as reachable. Such instances could be
# mitigated by clobbering any uninitialized data. Note that this won't cover
# all possible uninitialized stack contents, such as those used for register
# spill slots, unused portions for alignment, or even local variables not
# yet in scope at a certain point in the function.
#
# Note that this type of issue was discovered with lsan, but can apply to other
# sanitizers.
[sanitizer] Disable COMPILER_RT_HAS_TRIVIAL_AUTO_INIT on PowerPC to fix the bot See issue #84654.
2024-03-09 14:31:53 -08:00
# Disable PowerPC because of https://github.com/llvm/llvm-project/issues/84654.
if(NOT "${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "powerpc")
append_list_if(COMPILER_RT_HAS_TRIVIAL_AUTO_INIT -ftrivial-auto-var-init=pattern SANITIZER_COMMON_CFLAGS)
endif()
[compiler-rt] Add opt-in -ftrivial-auto-var-init flag for writing over uninitialized stack variiables This might allow lsan to find more leaks that would have gone undetected. When lsan searches for leaked pointers on the stack, if a leaked pointer that was pushed to the stack in a prior function call would not be scrubbed on a future function call, then the scan will see the pointer on the stack and not mark it as leaked. Such holes can exist in the lsan runtime where there may be uninitialized data. Adding auto-var-init can scrub some of that data and might be able to catch more leaks that would've gone undetected this way. See https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=111351 for more details. Differential Revision: https://reviews.llvm.org/D135716
2022-12-08 19:29:28 +00: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 03:39:38 +00:00
# Set common link flags.
[compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind We already link libunwind explicitly so avoid trying to link toolchain's default libunwind which may be missing. This matches what we already do for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D129472
2022-07-11 08:08:37 +00:00
# TODO: We should consider using the same model as libc++, that is use either
# -nostdlib++ and --unwindlib=none if supported, or -nodefaultlibs otherwise.
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 11:47:09 +02:00
append_list_if(C_SUPPORTS_NODEFAULTLIBS_FLAG -nodefaultlibs SANITIZER_COMMON_LINK_FLAGS)
[sanitizer] Build everything whereever possible with -z text. Reviewers: pcc, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58755 llvm-svn: 355164
2019-03-01 01:45:01 +00:00
append_list_if(COMPILER_RT_HAS_Z_TEXT -Wl,-z,text SANITIZER_COMMON_LINK_FLAGS)
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 03:39:38 +00:00
[compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`, `libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so` failed to link with undefined references to 64-bit atomics, which `clang` cannot inline. Even D130569 <https://reviews.llvm.org/D130569> didn't help because those libraries are linked with `-nodefaultlibs`, so dependent libraries need to be added explicitly. That's what this patch does. Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`. Differential Revision: https://reviews.llvm.org/D130571
2022-07-27 12:30:18 +02:00
# Only necessary for 32-bit SPARC. Solaris 11.2+ ld uses -z ignore/-z record
# natively, but supports --as-needed/--no-as-needed for GNU ld compatibility.
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "sparc")
list(APPEND SANITIZER_COMMON_LINK_LIBS -Wl,--as-needed atomic -Wl,--no-as-needed)
endif()
[CMake] Change the flag to use compiler-rt builtins to boolean This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 llvm-svn: 337116
2018-07-15 03:05:20 +00:00
if (COMPILER_RT_USE_BUILTINS_LIBRARY)
[CMake] When built with LLVM, not use `-Wl,-z,defs` This matches standalone build behavior. PR28681 Differential Revision: https://reviews.llvm.org/D53686 Patch By: tabloid.adroit llvm-svn: 345547
2018-10-29 22:16:56 +00:00
string(REPLACE "-Wl,-z,defs" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
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 03:39:38 +00:00
else()
[sanitizer] Fix the sanitizer build on Android Android uses libgcc name even for shared library unlike other platforms which use libgcc_s. Furthemore, Android libstdc++ has a dependency on libdl. These need to be handled while performing CMake checks. Differential Revision: https://reviews.llvm.org/D36035 llvm-svn: 309638
2017-07-31 22:46:43 +00:00
if (ANDROID)
append_list_if(COMPILER_RT_HAS_GCC_LIB gcc SANITIZER_COMMON_LINK_LIBS)
else()
append_list_if(COMPILER_RT_HAS_GCC_S_LIB gcc_s SANITIZER_COMMON_LINK_LIBS)
endif()
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 03:39:38 +00:00
endif()
append_list_if(COMPILER_RT_HAS_LIBC c SANITIZER_COMMON_LINK_LIBS)
[compiler-rt] Make use of undefined symbols configurable We want to disable the use of undefined symbols on Fuchsia, but there are cases where it might be desirable so may it configurable. Differential Revision: https://reviews.llvm.org/D104728
2021-06-22 11:03:37 -07:00
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Fuchsia")
list(APPEND SANITIZER_COMMON_LINK_LIBS zircon)
endif()
[compiler-rt][sanitizer] add Haiku support (#134772) Co-authored-by: Jérôme Duval <jerome.duval@gmail.com>
2025-04-11 16:21:00 -04:00
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Haiku")
list(APPEND SANITIZER_COMMON_LINK_LIBS root)
list(APPEND SANITIZER_COMMON_LINK_LIBS bsd)
endif()
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 03:39:38 +00:00
[sanitizer_common] Fuchsia OS support code Submitted on behalf of Roland McGrath. Reviewers: vitalybuka, alekseyshl, kcc Reviewed By: vitalybuka Subscribers: cryptoad, srhines, kubamracek, mgorny, phosek, filcab, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D36031 llvm-svn: 309756
2017-08-01 22:22:25 +00:00
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Fuchsia")
[compiler-rt] Make use of undefined symbols configurable We want to disable the use of undefined symbols on Fuchsia, but there are cases where it might be desirable so may it configurable. Differential Revision: https://reviews.llvm.org/D104728
2021-06-22 11:03:37 -07:00
set(SANITIZER_NO_UNDEFINED_SYMBOLS_DEFAULT ON)
else()
set(SANITIZER_NO_UNDEFINED_SYMBOLS_DEFAULT OFF)
endif()
option(SANITIZER_NO_UNDEFINED_SYMBOLS "Report error on unresolved symbol references" ${SANITIZER_NO_UNDEFINED_SYMBOLS_DEFAULT})
if (SANITIZER_NO_UNDEFINED_SYMBOLS)
[compiler-rt][CMake] Drop flags that are set by default for Fuchsia -Wl,-z,now is set by the Fuchsia driver, -Wl,-z,relro is the default in LLD.
2021-06-20 19:10:50 -07:00
list(APPEND SANITIZER_COMMON_LINK_FLAGS -Wl,-z,defs)
[sanitizer_common] Fuchsia OS support code Submitted on behalf of Roland McGrath. Reviewers: vitalybuka, alekseyshl, kcc Reviewed By: vitalybuka Subscribers: cryptoad, srhines, kubamracek, mgorny, phosek, filcab, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D36031 llvm-svn: 309756
2017-08-01 22:22:25 +00:00
endif()
[CMake] Avoid accidental C++ standard library dependency in sanitizers While sanitizers don't use C++ standard library, we could still end up accidentally including or linking it just by the virtue of using the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these accidental dependencies. Reviewed By: smeenai, vitalybuka Differential Revision: https://reviews.llvm.org/D88922
2020-10-30 20:19:39 -07:00
# TODO: COMPILER_RT_COMMON_CFLAGS and COMPILER_RT_COMMON_LINK_FLAGS are
# intended for use in non-sanitizer runtimes such as libFuzzer, profile or XRay,
# move these higher to include common flags, then derive SANITIZER_COMMON_CFLAGS
# and SANITIZER_COMMON_LINK_FLAGS from those and append sanitizer-specific flags.
set(COMPILER_RT_COMMON_CFLAGS ${SANITIZER_COMMON_CFLAGS})
set(COMPILER_RT_COMMON_LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS})
# We don't use the C++ standard library, so avoid including it by mistake.
append_list_if(COMPILER_RT_HAS_NOSTDINCXX_FLAG -nostdinc++ SANITIZER_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_NOSTDLIBXX_FLAG -nostdlib++ SANITIZER_COMMON_LINK_FLAGS)
# Remove -stdlib= which is unused when passing -nostdinc++...
[compiler-rt] Fix a bug in the cmakelists file when CMAKE_CXX_FLAGS are empty Right now, the regex expression will fail if the flags were not set. Instead, we should follow the pattern of other llvm projects and quote the expression, so that it can work even when the flags are not set. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D92586
2020-12-03 10:25:52 -08:00
string(REGEX MATCHALL "-stdlib=[a-zA-Z+]*" stdlib_flag "${CMAKE_CXX_FLAGS}")
string(REGEX REPLACE "-stdlib=[a-zA-Z+]*" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
[CMake] Avoid accidental C++ standard library dependency in sanitizers While sanitizers don't use C++ standard library, we could still end up accidentally including or linking it just by the virtue of using the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these accidental dependencies. Reviewed By: smeenai, vitalybuka Differential Revision: https://reviews.llvm.org/D88922
2020-10-30 20:19:39 -07:00
# ...we need it to build some runtimes and tests so readd it where appropriate.
list(APPEND COMPILER_RT_COMMON_CFLAGS ${stdlib_flag})
list(APPEND COMPILER_RT_COMMON_LINK_FLAGS ${stdlib_flag})
[CMake] Use explicit header path when using in-tree libc++ for tests This is a follow up to D118200 which applies a similar cleanup to headers when using in-tree libc++ to avoid accidentally picking up the system headers. Differential Revision: https://reviews.llvm.org/D128035
2022-06-17 08:11:32 +00:00
# TODO: There's a lot of duplication across lib/*/tests/CMakeLists.txt files,
# move some of the common flags to COMPILER_RT_UNITTEST_CFLAGS.
# Unittests need access to C++ standard library.
string(APPEND COMPILER_RT_TEST_COMPILER_CFLAGS " ${stdlib_flag}")
# When cross-compiling, COMPILER_RT_TEST_COMPILER_CFLAGS help in compilation
# and linking of unittests.
string(REPLACE " " ";" COMPILER_RT_UNITTEST_CFLAGS "${COMPILER_RT_TEST_COMPILER_CFLAGS}")
set(COMPILER_RT_UNITTEST_LINK_FLAGS ${COMPILER_RT_UNITTEST_CFLAGS})
Reland "[compiler-rt] Allow running tests without installing first" Currently, the testsuite uses the default runtimes path to find the runtimes libraries which may or may not match the just-built runtimes. This change uses the `-resource-dir` flag for clang whenever `COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` is set to ensure that we are actually testing the currently built libraries rather than the ones bundled with `${COMPILER_RT_TEST_COMPILER}`. The existing logic works fine when clang and compiler-rt share the same build directory ``-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`, but when building compiler-rt separately we need to tell the compiler used for the tests where it can find the just-built libraries. This reduces the fixes check-all failures to one in my configuration: ``` cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G Ninja -DCMAKE_C_COMPILER=$HOME/output/upstream-llvm/bin/clang -DCMAKE_CXX_COMPILER=$HOME/output/upstream-llvm/bin/clang++ -DCOMPILER_RT_INCLUDE_TESTS=ON -DLLVM_EXTERNAL_LIT=$HOME/build/upstream-llvm-project-build/bin/llvm-lit -DLLVM_CMAKE_DIR=$HOME/output/upstream-llvm -DCOMPILER_RT_DEBUG=OFF -S $HOME/src/upstream-llvm-project/compiler-rt -B $HOME/src/upstream-llvm-project/compiler-rt/cmake-build-all-sanitizers ``` This relands the previous PR with fixes for Windows. Depends on https://github.com/llvm/llvm-project/pull/88074 to be merged first for GCC buildbots. Pull Request: https://github.com/llvm/llvm-project/pull/88075
2024-04-12 13:20:30 -07: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)
if (COMPILER_RT_TEST_STANDALONE_BUILD_LIBS)
# Ensure that the unit tests can find the sanitizer headers prior to installation.
list(APPEND COMPILER_RT_UNITTEST_CFLAGS "-I${CMAKE_CURRENT_LIST_DIR}/include")
# Ensure that unit tests link against the just-built runtime libraries instead
# of the ones bundled with the compiler by overriding the resource directory.
#
if ("${COMPILER_RT_TEST_COMPILER_ID}" MATCHES "Clang")
list(APPEND COMPILER_RT_UNITTEST_LINK_FLAGS "-resource-dir=${COMPILER_RT_OUTPUT_DIR}")
endif()
endif()
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
if(COMPILER_RT_USE_LLVM_UNWINDER)
[compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind We already link libunwind explicitly so avoid trying to link toolchain's default libunwind which may be missing. This matches what we already do for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D129472
2022-07-11 08:08:37 +00:00
# We're linking directly against the libunwind that we're building so don't
# try to link in the toolchain's default libunwind which may be missing.
append_list_if(CXX_SUPPORTS_UNWINDLIB_NONE_FLAG --unwindlib=none COMPILER_RT_COMMON_LINK_FLAGS)
append_list_if(CXX_SUPPORTS_UNWINDLIB_NONE_FLAG --unwindlib=none COMPILER_RT_UNITTEST_LINK_FLAGS)
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
if (COMPILER_RT_ENABLE_STATIC_UNWINDER)
[compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind We already link libunwind explicitly so avoid trying to link toolchain's default libunwind which may be missing. This matches what we already do for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D129472
2022-07-11 08:08:37 +00:00
list(APPEND COMPILER_RT_UNWINDER_LINK_LIBS "$<TARGET_LINKER_FILE:unwind_static>")
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
else()
[Fuchsia][cmake] Avoid referencing cxx_shared in compiler-rt (#112257) After https://github.com/llvm/llvm-project/pull/80007 Fuchsia builds are now always building cxx_shared for arm64 and x64 Linux. Ultimately, this is because the LIBCXX_ENABLE_SHARED is not used in compiler-rt to select the correct libc++ target, and because cxx_shared is now always defined, it is selected as a dependency when building runtimes tests. --------- Co-authored-by: Petr Hosek <phosek@google.com>
2024-10-14 14:41:19 -07:00
list(APPEND COMPILER_RT_UNWINDER_LINK_LIBS "$<TARGET_LINKER_FILE:$<IF:$<BOOL:${LIBUNWIND_ENABLE_SHARED}>,unwind_shared,unwind_static>>")
[CMake][compiler-rt] Provide a dedicated option for LLVM unwinder This allows configuring LLVM unwinder separately from the C++ library matching how we configure it in libcxx. This also applies changes made to libunwind+libcxxabi+libcxx in D113253 to compiler-rt. Differential Revision: https://reviews.llvm.org/D115674
2022-04-26 23:23:53 -07:00
endif()
endif()
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
if (COMPILER_RT_CXX_LIBRARY STREQUAL "libcxx")
# We are using the in-tree libc++ so avoid including the default one.
append_list_if(COMPILER_RT_HAS_NOSTDINCXX_FLAG -nostdinc++ COMPILER_RT_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_NOSTDLIBXX_FLAG -nostdlib++ COMPILER_RT_COMMON_LINK_FLAGS)
# Use the in-tree libc++ through explicit include and library paths.
[CMake] Use correct include flag for MSVC When building using the MSVC driver, we need to use /imsvc rather than -isystem for system headers. Differential Revision: https://reviews.llvm.org/D134864
2022-09-29 08:48:03 +00:00
set(COMPILER_RT_CXX_CFLAGS "$<$<TARGET_EXISTS:cxx-headers>:$<IF:$<BOOL:${MSVC}>,/imsvc,-isystem>$<JOIN:$<TARGET_PROPERTY:cxx-headers,INTERFACE_INCLUDE_DIRECTORIES>,$<SEMICOLON>$<IF:$<BOOL:${MSVC}>,/imsvc,-isystem>>>")
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
if (COMPILER_RT_STATIC_CXX_LIBRARY)
[compiler-rt][CMake] Use linker semantics for unwinder and C++ library Try the shared library first, and if it doesn't exist fallback onto the static one. When the static library is requested, skip the shared library. Differential Revision: https://reviews.llvm.org/D129470
2022-07-11 08:18:28 +00:00
set(COMPILER_RT_CXX_LINK_LIBS "$<TARGET_LINKER_FILE:cxx_static>")
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
else()
[Fuchsia][cmake] Avoid referencing cxx_shared in compiler-rt (#112257) After https://github.com/llvm/llvm-project/pull/80007 Fuchsia builds are now always building cxx_shared for arm64 and x64 Linux. Ultimately, this is because the LIBCXX_ENABLE_SHARED is not used in compiler-rt to select the correct libc++ target, and because cxx_shared is now always defined, it is selected as a dependency when building runtimes tests. --------- Co-authored-by: Petr Hosek <phosek@google.com>
2024-10-14 14:41:19 -07:00
set(COMPILER_RT_CXX_LINK_LIBS "$<TARGET_LINKER_FILE:$<IF:$<BOOL:${LIBCXX_ENABLE_SHARED}>,cxx_shared,cxx_static>>")
[CMake] Option to select C++ library for runtimes that use it We currently have an option to select C++ ABI and C++ library for tests but there are runtimes that use C++ library, specifically ORC and XRay, which aren't covered by existing options. This change introduces a new option to control the use of C++ libray for these runtimes. Ideally, this option should become the default way to select C++ library for all of compiler-rt replacing the existing options (the C++ ABI option could remain as a hidden internal option). Differential Revision: https://reviews.llvm.org/D128036
2022-06-02 21:52:56 +00:00
endif()
elseif (COMPILER_RT_CXX_LIBRARY STREQUAL "none")
# We aren't using any C++ standard library so avoid including the default one.
append_list_if(COMPILER_RT_HAS_NOSTDINCXX_FLAG -nostdinc++ COMPILER_RT_COMMON_CFLAGS)
append_list_if(COMPILER_RT_HAS_NOSTDLIBXX_FLAG -nostdlib++ COMPILER_RT_COMMON_LINK_FLAGS)
else()
# Nothing to be done for `default`.
endif()
[NFC][CMake] Inline the append_libcxx_libs macro This is only invoked from a single site and doesn't add any value.
2022-09-29 06:51:43 +00:00
if (SANITIZER_CXX_ABI_LIBNAME STREQUAL "libc++")
if (SANITIZER_CXX_ABI_INTREE)
[compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind We already link libunwind explicitly so avoid trying to link toolchain's default libunwind which may be missing. This matches what we already do for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D129472
2022-07-11 08:08:37 +00:00
# TODO: We don't need to add --unwindlib=none to SANITIZER_COMMON_LINK_FLAGS
# because we added -nodefaultlibs there earlier, and adding would result in
# a warning, but if we switch to -nostdlib++, we would need to add it here.
# append_list_if(CXX_SUPPORTS_UNWINDLIB_NONE_FLAG --unwindlib=none SANITIZER_COMMON_LINK_FLAGS)
[CMake] Use libcxx-abi-* targets for in-tree sanitizer C++ ABI When in-tree libcxx is selected as the sanitizer C++ ABI, use libcxx-abi-* targets rather than libcxxabi and libunwind directly. Differential Revision: https://reviews.llvm.org/D134855
2022-09-29 07:53:06 +00:00
if(SANITIZER_USE_STATIC_CXX_ABI)
if(TARGET libcxx-abi-static)
set(SANITIZER_CXX_ABI_LIBRARIES libcxx-abi-static)
endif()
else()
if(TARGET libcxx-abi-shared)
set(SANITIZER_CXX_ABI_LIBRARIES libcxx-abi-shared)
elseif(TARGET libcxx-abi-static)
set(SANITIZER_CXX_ABI_LIBRARIES libcxx-abi-static)
endif()
[CMake] Support libc++ as Clang default stdlib in compiler-rt Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
2018-05-22 18:33:27 +00:00
endif()
else()
[NFC][CMake] Inline the append_libcxx_libs macro This is only invoked from a single site and doesn't add any value.
2022-09-29 06:51:43 +00:00
append_list_if(COMPILER_RT_HAS_LIBCXX c++ SANITIZER_CXX_ABI_LIBRARIES)
[CMake] Support libc++ as Clang default stdlib in compiler-rt Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
2018-05-22 18:33:27 +00:00
endif()
Add libcxxabi option back for sanitizer use. Summary: A prior refactoring accidentally dropped the case for using libc++abi as the out-of-tree C++ runtime library for sanitizers. This patch restores that functionality, which is used by Android, which can't depend on the full libc++ for these libraries. Reviewers: phosek, EricWF Reviewed By: phosek Subscribers: meikeb, kongyi, chh, mgorny, delcypher, llvm-commits, #sanitizers, pirama Differential Revision: https://reviews.llvm.org/D49157 llvm-svn: 336749
2018-07-11 00:50:03 +00:00
elseif (SANITIZER_CXX_ABI_LIBNAME STREQUAL "libcxxabi")
[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 08:34:26 +00:00
list(APPEND SANITIZER_CXX_ABI_LIBRARIES "c++abi")
[CMake] Support libc++ as Clang default stdlib in compiler-rt Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
2018-05-22 18:33:27 +00:00
elseif (SANITIZER_CXX_ABI_LIBNAME STREQUAL "libstdc++")
[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 08:34:26 +00:00
append_list_if(COMPILER_RT_HAS_LIBSTDCXX stdc++ SANITIZER_CXX_ABI_LIBRARIES)
endif()
if (SANITIZER_TEST_CXX_LIBNAME STREQUAL "libc++")
[CMake] Handle in-tree libc++ for sanitizer tests We have been relying on the logic for C++ ABI library for sanitizer tests but that's incorrect since most tests require a full C++ library and not just C++ ABI. This change tries to address this by using the dependency on libc++ if available. Differential Revision: https://reviews.llvm.org/D118163
2022-01-25 09:42:28 -08:00
if (SANITIZER_TEST_CXX_INTREE)
[CMake] Use correct include flag for MSVC When building using the MSVC driver, we need to use /imsvc rather than -isystem for system headers. Differential Revision: https://reviews.llvm.org/D134864
2022-09-29 08:48:03 +00:00
list(APPEND SANITIZER_TEST_CXX_CFLAGS "$<$<TARGET_EXISTS:cxx-headers>:$<IF:$<BOOL:${MSVC}>,/imsvc,-isystem>$<JOIN:$<TARGET_PROPERTY:cxx-headers,INTERFACE_INCLUDE_DIRECTORIES>,$<SEMICOLON>$<IF:$<BOOL:${MSVC}>,/imsvc,-isystem>>>")
[CMake] Use generator expression to get in-tree libc++ path When using the in-tree libc++, we should be using the full path to ensure that we're using the right library and not accidentally pick up the system library. Differential Revision: https://reviews.llvm.org/D118200
2022-01-25 16:10:51 -08:00
if (SANITIZER_USE_STATIC_TEST_CXX)
[compiler-rt][CMake] Use linker semantics for unwinder and C++ library Try the shared library first, and if it doesn't exist fallback onto the static one. When the static library is requested, skip the shared library. Differential Revision: https://reviews.llvm.org/D129470
2022-07-11 08:18:28 +00:00
list(APPEND SANITIZER_TEST_CXX_LIBRARIES "$<TARGET_LINKER_FILE:cxx_static>")
[CMake] Use generator expression to get in-tree libc++ path When using the in-tree libc++, we should be using the full path to ensure that we're using the right library and not accidentally pick up the system library. Differential Revision: https://reviews.llvm.org/D118200
2022-01-25 16:10:51 -08:00
else()
[Fuchsia][cmake] Avoid referencing cxx_shared in compiler-rt (#112257) After https://github.com/llvm/llvm-project/pull/80007 Fuchsia builds are now always building cxx_shared for arm64 and x64 Linux. Ultimately, this is because the LIBCXX_ENABLE_SHARED is not used in compiler-rt to select the correct libc++ target, and because cxx_shared is now always defined, it is selected as a dependency when building runtimes tests. --------- Co-authored-by: Petr Hosek <phosek@google.com>
2024-10-14 14:41:19 -07:00
list(APPEND SANITIZER_TEST_CXX_LIBRARIES "$<TARGET_LINKER_FILE:$<IF:$<BOOL:${LIBCXX_ENABLE_SHARED}>,cxx_shared,cxx_static>>")
[CMake] Handle in-tree libc++ for sanitizer tests We have been relying on the logic for C++ ABI library for sanitizer tests but that's incorrect since most tests require a full C++ library and not just C++ ABI. This change tries to address this by using the dependency on libc++ if available. Differential Revision: https://reviews.llvm.org/D118163
2022-01-25 09:42:28 -08:00
endif()
[CMake] Use explicit header path when using in-tree libc++ for tests This is a follow up to D118200 which applies a similar cleanup to headers when using in-tree libc++ to avoid accidentally picking up the system headers. Differential Revision: https://reviews.llvm.org/D128035
2022-06-17 08:11:32 +00:00
# We are using the in tree libc++ so avoid including the default one.
append_list_if(COMPILER_RT_HAS_NOSTDINCXX_FLAG -nostdinc++ COMPILER_RT_UNITTEST_CFLAGS)
append_list_if(COMPILER_RT_HAS_NOSTDLIBXX_FLAG -nostdlib++ COMPILER_RT_UNITTEST_LINK_FLAGS)
[CMake] Handle in-tree libc++ for sanitizer tests We have been relying on the logic for C++ ABI library for sanitizer tests but that's incorrect since most tests require a full C++ library and not just C++ ABI. This change tries to address this by using the dependency on libc++ if available. Differential Revision: https://reviews.llvm.org/D118163
2022-01-25 09:42:28 -08:00
else()
[CMake] Use generator expression to get in-tree libc++ path When using the in-tree libc++, we should be using the full path to ensure that we're using the right library and not accidentally pick up the system library. Differential Revision: https://reviews.llvm.org/D118200
2022-01-25 16:10:51 -08:00
append_list_if(COMPILER_RT_HAS_LIBCXX -lc++ SANITIZER_TEST_CXX_LIBRARIES)
[CMake] Handle in-tree libc++ for sanitizer tests We have been relying on the logic for C++ ABI library for sanitizer tests but that's incorrect since most tests require a full C++ library and not just C++ ABI. This change tries to address this by using the dependency on libc++ if available. Differential Revision: https://reviews.llvm.org/D118163
2022-01-25 09:42:28 -08:00
endif()
[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 08:34:26 +00:00
elseif (SANITIZER_TEST_CXX_LIBNAME STREQUAL "libstdc++")
[CMake] Use generator expression to get in-tree libc++ path When using the in-tree libc++, we should be using the full path to ensure that we're using the right library and not accidentally pick up the system library. Differential Revision: https://reviews.llvm.org/D118200
2022-01-25 16:10:51 -08:00
append_list_if(COMPILER_RT_HAS_LIBSTDCXX -lstdc++ SANITIZER_TEST_CXX_LIBRARIES)
[CMake] Support libc++ as Clang default stdlib in compiler-rt Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
2018-05-22 18:33:27 +00:00
endif()
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 16:16:09 -07:00
# Unittests support.
cmake: Fix build with -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON This was broken by a11cd0d94ed3cabf0998a0289aead05da94c86eb.
2022-11-10 00:31:01 +00:00
# FIXME: When compiler-rt is build using -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON, then
# The LLVM_THIRD_PARTY_DIR variable is not set.
if (NOT LLVM_THIRD_PARTY_DIR)
set(LLVM_THIRD_PARTY_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../third-party")
endif()
Move googletest to the third-party directory Rre-commit of 59052468c3e38cab15582cefbb5133fd4c2ffce5 with a typo fix in compiler-rt/CMakeLists.txt
2022-11-09 08:51:34 -08:00
set(COMPILER_RT_GTEST_PATH ${LLVM_THIRD_PARTY_DIR}/unittest/googletest)
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 16:16:09 -07:00
set(COMPILER_RT_GTEST_SOURCE ${COMPILER_RT_GTEST_PATH}/src/gtest-all.cc)
set(COMPILER_RT_GTEST_CFLAGS
-DGTEST_NO_LLVM_SUPPORT=1
-DGTEST_HAS_RTTI=0
-I${COMPILER_RT_GTEST_PATH}/include
-I${COMPILER_RT_GTEST_PATH}
)
# Mocking support.
Move googletest to the third-party directory Rre-commit of 59052468c3e38cab15582cefbb5133fd4c2ffce5 with a typo fix in compiler-rt/CMakeLists.txt
2022-11-09 08:51:34 -08:00
set(COMPILER_RT_GMOCK_PATH ${LLVM_THIRD_PARTY_DIR}/unittest/googlemock)
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 16:16:09 -07:00
set(COMPILER_RT_GMOCK_SOURCE ${COMPILER_RT_GMOCK_PATH}/src/gmock-all.cc)
set(COMPILER_RT_GMOCK_CFLAGS
-DGTEST_NO_LLVM_SUPPORT=1
-DGTEST_HAS_RTTI=0
-I${COMPILER_RT_GMOCK_PATH}/include
-I${COMPILER_RT_GMOCK_PATH}
)
sanitizers: build tests with -g We currently build tests without -g, which is quite inconvenient. Crash stacks don't have line numbers, gdb don't how line numbers either. Always build tests with -g. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107168
2021-07-30 16:56:36 +02:00
if(COMPILER_RT_HAS_G_FLAG)
list(APPEND COMPILER_RT_UNITTEST_CFLAGS -g)
endif()
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 16:16:09 -07:00
append_list_if(COMPILER_RT_DEBUG -DSANITIZER_DEBUG=1 COMPILER_RT_UNITTEST_CFLAGS)
append_list_if(COMPILER_RT_HAS_WCOVERED_SWITCH_DEFAULT_FLAG -Wno-covered-switch-default COMPILER_RT_UNITTEST_CFLAGS)
append_list_if(COMPILER_RT_HAS_WSUGGEST_OVERRIDE_FLAG -Wno-suggest-override COMPILER_RT_UNITTEST_CFLAGS)
[GTest][c++17] Silence warnings when building GTest with gcc-toolset-12 This change fixes a build break introduced by aafad2d(#70353) on the clang-ppc64le-rhel build bot. If the third-party Google Test suite is built using gcc-toolset-12, the implementation of std::stable_sort in the toolchain will use a get_temporary_buffer declaration that is marked _GLIBCXX17_DEPRECATED. This change adds -Wno-deprecated-declarations to the GTest flags if the toolchain is detected in the build compiler on linux.
2023-12-05 13:29:46 -05:00
# Detect if the compiler toolchain includes gcc-toolset-12.
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" OR
"${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
execute_process(COMMAND ${CMAKE_CXX_COMPILER} -v
RESULT_VARIABLE compiler_info_rc
OUTPUT_VARIABLE compiler_info
ERROR_VARIABLE compiler_info)
if(compiler_info MATCHES ".*gcc-toolset-12.*")
set(USING_GCC_TOOLSET_12 TRUE)
endif()
endif()
if(MSVC OR (LINUX AND DEFINED USING_GCC_TOOLSET_12 AND
CMAKE_CXX_STANDARD EQUAL 17))
# gtest use a lot of stuff marked as deprecated on Windows or if using
# gcc-toolset-12 in the compiler toolchain on Linux; all of the
# deprecated declarations in gcc-toolset-12 used in Google Tests have been
# observed to be _GLIBCXX17_DEPRECATED and should go away once
# CMAKE_CXX_STANDARD is greater than 17.
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 16:16:09 -07:00
list(APPEND COMPILER_RT_GTEST_CFLAGS -Wno-deprecated-declarations)
endif()
Turn off -Wunused-parameter when building compiler-rt with clang on Windows, it is very noisy It is turned on as part of "clang-cl /W4", which enables -Wextra. llvm-svn: 273028
2016-06-17 18:30:37 +00:00
# Warnings to turn off for all libraries, not just sanitizers.
append_string_if(COMPILER_RT_HAS_WUNUSED_PARAMETER_FLAG -Wno-unused-parameter CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[compiler-rt] suppress LNK4221 warning when creating static libraries Summary: We put empty object files in archives, which causes MSVC's linker to complain about these objects not defining any previously undefined symbols. Since we do it on purpose, this only creates noise during the build process. This patch causes us to suppress the warnings. Reviewers: rnk, samsonov Subscribers: dberris, mgorny Differential Revision: https://reviews.llvm.org/D28262 llvm-svn: 291011
2017-01-04 21:40:00 +00:00
if (CMAKE_LINKER MATCHES "link.exe$")
# Silence MSVC linker warnings caused by empty object files. The
# sanitizer libraries intentionally use ifdefs that result in empty
# files, rather than skipping these files in the build system.
# Ideally, we would pass this flag only for the libraries that need
# it, but CMake doesn't seem to have a way to set linker flags for
# individual static libraries, so we enable the suppression flag for
# the whole compiler-rt project.
[compiler-rt][MSVC][CMake] Wrap Linker flags for ICX (#118496) RFC: https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446 My previous pass missed some flags because I used `-Werror=unknown-argument`, but `/D`, `/I` and `/O` are accepted by clang (even when only linking), but mean different things than intended for `link.exe`.
2024-12-04 10:09:29 +01:00
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${CMAKE_CXX_LINKER_WRAPPER_FLAG}/IGNORE:4221")
[compiler-rt] suppress LNK4221 warning when creating static libraries Summary: We put empty object files in archives, which causes MSVC's linker to complain about these objects not defining any previously undefined symbols. Since we do it on purpose, this only creates noise during the build process. This patch causes us to suppress the warnings. Reviewers: rnk, samsonov Subscribers: dberris, mgorny Differential Revision: https://reviews.llvm.org/D28262 llvm-svn: 291011
2017-01-04 21:40:00 +00:00
endif()
Explicitly list all sanitizer headers in CMake build rules. Make sure sanitizer lit_tests depend on fresh headers. llvm-svn: 179293
2013-04-11 15:49:52 +00:00
add_subdirectory(include)
[compiler-rt] Add option to disable libc++ build Having libc++ checked out doesn't necessarily mean it should be built; for example, the same source tree might be used for multiple build configurations, and libc++ might not build in some of those configurations. Add an option to compiler-rt's build to disable building libc++. This defaults to ON, so it shouldn't change any existing build configurations. Differential Revision: https://reviews.llvm.org/D56479 llvm-svn: 351117
2019-01-14 20:33:30 +00:00
option(COMPILER_RT_USE_LIBCXX
"Enable compiler-rt to use libc++ from the source tree" ON)
Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi" This reverts commit 4164cfa537e545f8ea9bc4f3c8b913867a7ac79d since it broke the clang-x86_64-debian-fast builder: https://lab.llvm.org/buildbot/#/builders/109/builds/41339
2022-06-25 03:10:55 +00:00
if(COMPILER_RT_USE_LIBCXX)
if(LLVM_ENABLE_PROJECTS_USED)
# Don't use libcxx if LLVM_ENABLE_PROJECTS does not enable it.
set(COMPILER_RT_LIBCXX_PATH ${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR})
set(COMPILER_RT_LIBCXXABI_PATH ${LLVM_EXTERNAL_LIBCXXABI_SOURCE_DIR})
Revert "Fix locating of COMPILER_RT_LIBCXX_PATH" clang-aarch64-sve-vla crashes in msan clang-s390x-linux-lnt fails to compile libcxx This reverts commit 14b2b67cd7d5e439c4bc5c8051f68a5fbb683480.
2022-10-11 23:24:13 -07:00
else()
Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi" This reverts commit 4164cfa537e545f8ea9bc4f3c8b913867a7ac79d since it broke the clang-x86_64-debian-fast builder: https://lab.llvm.org/buildbot/#/builders/109/builds/41339
2022-06-25 03:10:55 +00:00
foreach(path IN ITEMS ${LLVM_MAIN_SRC_DIR}/projects/libcxx
${LLVM_MAIN_SRC_DIR}/runtimes/libcxx
${LLVM_MAIN_SRC_DIR}/../libcxx
${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR})
if(IS_DIRECTORY ${path})
set(COMPILER_RT_LIBCXX_PATH ${path})
break()
endif()
endforeach()
foreach(path IN ITEMS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi
${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi
${LLVM_MAIN_SRC_DIR}/../libcxxabi
${LLVM_EXTERNAL_LIBCXXABI_SOURCE_DIR})
if(IS_DIRECTORY ${path})
set(COMPILER_RT_LIBCXXABI_PATH ${path})
break()
endif()
endforeach()
endif()
endif()
Move MSan lit-tests under test/msan llvm-svn: 201412
2014-02-14 13:02:58 +00:00
[test][sanitizer] Check LINKER_IS_LLD to detect LLD This enables some tests requiring LLD when we test compiler-rt activated with LLVM_ENABLE_RUNTIMES.
2023-09-11 11:01:37 -07:00
if (LINKER_IS_LLD OR LLVM_TOOL_LLD_BUILD)
set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/tools/lld)
if(EXISTS ${COMPILER_RT_LLD_PATH}/)
Revert "Reland [compiler-rt][CMake] Properly set COMPILER_RT_HAS_LLD" This reverts commit fffa05a2bcb548d5189e8c2e52d2ed2e7ebb2498. This seems to cause hwasan tests to run in environments it didn't run in before.
2023-06-06 15:59:26 -07:00
set(COMPILER_RT_HAS_LLD TRUE)
[test][sanitizer] Check LINKER_IS_LLD to detect LLD This enables some tests requiring LLD when we test compiler-rt activated with LLVM_ENABLE_RUNTIMES.
2023-09-11 11:01:37 -07:00
else()
set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/../lld)
if(EXISTS ${COMPILER_RT_LLD_PATH}/)
set(COMPILER_RT_HAS_LLD TRUE)
endif()
Revert "Reland [compiler-rt][CMake] Properly set COMPILER_RT_HAS_LLD" This reverts commit fffa05a2bcb548d5189e8c2e52d2ed2e7ebb2498. This seems to cause hwasan tests to run in environments it didn't run in before.
2023-06-06 15:59:26 -07:00
endif()
[cmake] Hoist check for LLD sources up into root CMakeLists.txt We will use this for ASan on Windows soon. When the ELF port of LLD matures, we can add other sanitizer integration tests to make sure they work with LLD. llvm-svn: 244549
2015-08-11 00:33:07 +00:00
endif()
Use LLD for Android compiler-rt Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D90720
2020-11-03 16:10:35 -08:00
if(ANDROID)
set(COMPILER_RT_HAS_LLD TRUE)
set(COMPILER_RT_TEST_USE_LLD TRUE)
append_list_if(COMPILER_RT_HAS_FUSE_LD_LLD_FLAG -fuse-ld=lld SANITIZER_COMMON_LINK_FLAGS)
append_list_if(COMPILER_RT_HAS_LLD -fuse-ld=lld COMPILER_RT_UNITTEST_LINK_FLAGS)
endif()
[compiler-rt][test] Disable lld tests on SPARC (#100533) As detailed in Issue #100320, a considerable number of tests that explicitly use `-fuse-ld=lld` `FAIL` on Linux/sparc64 due to several `lld` limitations (no 32-bit SPARC support, lack of support for various relocations, ...). To reduce the noise, this patch disables `COMPILER_RT_HAS_LLD` on SPARC wholesale. Tested on `sparc64-unknown-linux-gnu`.
2024-07-29 09:12:15 +02:00
if(${COMPILER_RT_DEFAULT_TARGET_ARCH} MATCHES sparc)
# lld has several bugs/limitations on SPARC, so disable (Issue #100320).
set(COMPILER_RT_HAS_LLD FALSE)
endif()
Fix sanitizer tests with LLVM_TOOL_LLD_BUILD=OFF. Only depend on LLD if it is going to be built. Re-land of r298174 which got reverted in r298287. llvm-svn: 298753
2017-03-25 00:42:25 +00:00
pythonize_bool(COMPILER_RT_HAS_LLD)
Use LLD for Android compiler-rt Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D90720
2020-11-03 16:10:35 -08:00
pythonize_bool(COMPILER_RT_TEST_USE_LLD)
[cmake] Hoist check for LLD sources up into root CMakeLists.txt We will use this for ASan on Windows soon. When the ELF port of LLD matures, we can add other sanitizer integration tests to make sure they work with LLD. llvm-svn: 244549
2015-08-11 00:33:07 +00:00
[sanitizer] Add CMake flag to build with internal symbolizer This intermediate result in moving internal symbolizer build from sh script to CMake rules. The flag is supposed to be used with: -DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" -DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi" -Sllvm-project/llvm After converting sh script into cmake, we may add support for other build modes. For https://github.com/llvm/llvm-project/issues/30098 Reviewed By: kstoimenov, MaskRay Differential Revision: https://reviews.llvm.org/D157947
2023-09-08 11:06:51 -07:00
option(COMPILER_RT_ENABLE_INTERNAL_SYMBOLIZER "Build Compiler RT linked with in LLVM symbolizer" OFF)
mark_as_advanced(COMPILER_RT_ENABLE_INTERNAL_SYMBOLIZER)
Add cmake option to enable/disable searching PATH for symbolizer (#129012) Introduced a cmake option that is disabled by default that suppresses searching via the PATH variable for a symbolizer. The option will be enabled for downstream builds where the user will need to specify the symbolizer path more explicitly, e.g., by using ASAN_SYMBOLIZER_PATH.
2025-03-26 04:59:35 +05:30
option(SANITIZER_DISABLE_SYMBOLIZER_PATH_SEARCH "Disable searching for external symbolizer in $PATH" OFF)
mark_as_advanced(SANITIZER_DISABLE_SYMBOLIZER_PATH_SEARCH)
if (SANITIZER_DISABLE_SYMBOLIZER_PATH_SEARCH)
add_compile_definitions(SANITIZER_DISABLE_SYMBOLIZER_PATH_SEARCH)
endif()
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-04 22:12:04 +00:00
add_subdirectory(lib)
[CMake] Introduce COMPILER_RT_INCLUDE_TESTS option llvm-svn: 201666
2014-02-19 11:18:47 +00:00
if(COMPILER_RT_INCLUDE_TESTS)
[compiler-rt] Don't build llvm-lit in RUNTIMES-BUILD With runtimes-build, we lost map config for llvm-lit, so we can NOT run lit from source dir anymore. All the subdir target like: ninja check-llvm-codegen-powerpc will fail too. We will get some cfg error like: File "../lvm-project/llvm/test/lit.cfg.py", line 21, in <module> config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell) AttributeError: 'NoneType' object has no attribute 'use_lit_shell' This is reset of map config in llvm-lit rebuild. We already have llvm-lit in runtimes-build, so don't build it. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D87002
2020-09-02 20:41:15 +00:00
# Don't build llvm-lit for runtimes-build, it will clean up map_config.
[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 00:39:50 -08:00
if (COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
# If we have a valid source tree, generate llvm-lit into the bin directory.
# The user can still choose to have the check targets *use* a different lit
# by specifying -DLLVM_EXTERNAL_LIT, but we generate it regardless.
if (EXISTS ${LLVM_MAIN_SRC_DIR}/utils/llvm-lit)
Reland "Make llvm_source_root in llvm-lit relative too." This reverts commit 3185881d69022e03b300e189838b0599ed417be5 and adds a missing "include(AddLLVM)" (similar lines already exist elsewhere in compiler-rt).
2020-04-06 20:38:26 -04:00
# Needed for lit support in standalone builds.
include(AddLLVM)
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit ${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
[compiler-rt] Use locally configured llvm-lit for standalone builds (#83178) When building a standalone build with `-DLLVM_CMAKE_DIR=$HOME/output/llvm-install -DCOMPILER_RT_INCLUDE_TESTS=ON`, the current code will attempt to use `LLVM_DEFAULT_EXTERNAL_LIT` which is set to `$HOME/output/llvm-install/bin/llvm-lit` inside `LLVMConfig.cmake` even though it is not actually installed. If we are adding the llvm-lit subdirectory, we can use `get_llvm_lit_path()` immediately afterwards to set LLVM_EXTERNAL_LIT so that subsequent calls within `add_lit_testsuite()` use llvm-lit from the current build directory instead of the nonexistant one.
2024-02-27 13:00:07 -08:00
# Ensure that the testsuite uses the local lit rather than
# LLVM_INSTALL_DIR/bin/llvm-lit (which probably does not exist).
get_llvm_lit_path(_base_dir _file_name)
set(LLVM_EXTERNAL_LIT "${_base_dir}/${_file_name}" CACHE STRING "Command used to spawn lit" FORCE)
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
elseif(NOT EXISTS ${LLVM_EXTERNAL_LIT})
message(WARNING "Could not find LLVM source directory and LLVM_EXTERNAL_LIT does not"
"point to a valid file. You will not be able to run tests.")
endif()
endif()
[compiler-rt] Use locally configured llvm-lit for standalone builds (#83178) When building a standalone build with `-DLLVM_CMAKE_DIR=$HOME/output/llvm-install -DCOMPILER_RT_INCLUDE_TESTS=ON`, the current code will attempt to use `LLVM_DEFAULT_EXTERNAL_LIT` which is set to `$HOME/output/llvm-install/bin/llvm-lit` inside `LLVMConfig.cmake` even though it is not actually installed. If we are adding the llvm-lit subdirectory, we can use `get_llvm_lit_path()` immediately afterwards to set LLVM_EXTERNAL_LIT so that subsequent calls within `add_lit_testsuite()` use llvm-lit from the current build directory instead of the nonexistant one.
2024-02-27 13:00:07 -08:00
add_subdirectory(unittests)
add_subdirectory(test)
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-04 22:12:04 +00:00
endif()
Add GWP-ASan fuzz target to compiler-rt/tools. Summary: @eugenis to approve addition of //compiler-rt/tools. @pree-jackie please confirm that this WFY. D66494 introduced the GWP-ASan stack_trace_compressor_fuzzer. Building fuzz targets in compiler-rt is a new affair, and has some challenges: - If the host compiler doesn't have compiler-rt, the -fsanitize=fuzzer may not be able to link against `libclang_rt.fuzzer*`. - Things in compiler-rt generally aren't built when you want to build with sanitizers using `-DLLVM_USE_SANITIZER`. This tricky to work around, so we create the new tools directory so that we can build fuzz targets with sanitizers. This has the added bonus of fixing the problem above as well, as we can now just guard the fuzz target build to only be done with `-DLLVM_USE_SANITIZE_COVERAGE=On`. Reviewers: eugenis, pree-jackie Reviewed By: eugenis, pree-jackie Subscribers: dberris, mgorny, #sanitizers, llvm-commits, eugenis, pree-jackie, lebedev.ri, vitalybuka, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D66776 llvm-svn: 370094
2019-08-27 18:28:07 +00:00
add_subdirectory(tools)
Reference in New Issue Copy Permalink