Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2024-12-03 11:23:58 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
e5a4d0f149
llvm-capstone/compiler-rt/CMakeLists.txt

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

678 lines
27 KiB
CMake
Raw Normal View History

Initial, very rough cut at a new CMake build system for compiler-rt. Some high-level notes: 1) An explicit goal is to support building compiler-rt as a subproject build, checked out into the projects/compiler-rt directory. There are many other possible ways of building the code here, but this is optimized for development on LLVM/Clang/compiler-rt, and incremental trial and testing of the toolchain. 2) The current support is targeted at Linux. I would love to see this generalized to other platforms, but for the sake of simplicity in testing, I'm focusing here first. Much of this patch was paired with Manuel, and I credit him with the majority of the work here. Some important caveats that I'll be working on in subsequent patches: 1) This uses the host compiler rather than using the just-built-clang. 2) Currently only x86 is supported. 3) Currently, none of the tests are built or run. 4) Uses CMake's builtin globbing which doesn't update correctly. 5) This is still turned off from LLVM's CMake build until these issues are addressed llvm-svn: 154060
2012-04-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.
[CMake] Bump CMake minimum version to 3.13.4 This upgrade should be friction-less because we've already been ensuring that CMake >= 3.13.4 is used. This is part of the effort discussed on llvm-dev here: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html Differential Revision: https://reviews.llvm.org/D78648
2020-04-22 15:15:05 +00:00
cmake_minimum_required(VERSION 3.13.4)
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
[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
# Check if compiler-rt is built as a standalone project.
[CMake] Fix ASM building in llvm/runtimes When compiler-rt's CMake is not directly invoked, it will currently not call project() and thus ASM will not be enabled. We also don't need to put the .S files through the C compiler then. Differential Revision: https://reviews.llvm.org/D23656 llvm-svn: 279215
2016-08-19 06:46:00 +00:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR COMPILER_RT_STANDALONE_BUILD)
Let cmake infer source file language by the file extension. This applies default compiler flags to .S files, in particular removing the "-pedantic" option, which is desirable because there is nothing to reasonably warn about; and the only thing that gcc warns about is that you allegedly can't correctly invoke GLUE2 in lib/builtins/assembly.h on platforms for which USER_LABEL_PREFIX is the empty string. In the gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305 that added the warning, a commenter notes that giving a macro of zero characters to another macro is not precisely the same as failing to supply an argument, and "there is a widespread belief in C++ community that such usage is valid". Unfortunately the only way to silence the warning is to avoid -pedantic. Differential Revision: http://reviews.llvm.org/D10713 llvm-svn: 243446
2015-07-28 16:52:42 +00:00
project(CompilerRT C CXX ASM)
[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
set(COMPILER_RT_STANDALONE_BUILD TRUE)
[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
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
[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] 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] Cache the compiler-rt library search results There's a lot of duplicated calls to find various compiler-rt libraries from build of runtime libraries like libunwind, libc++, libc++abi and compiler-rt. The compiler-rt helper module already implemented caching for results avoid repeated Clang invocations. This change moves the compiler-rt implementation into a shared location and reuses it from other runtimes to reduce duplication and speed up the build. Differential Revision: https://reviews.llvm.org/D88458
2020-09-29 00:37:20 +00:00
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake/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] 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)
Add top-level CMake 'compiler-rt' target to build all compiler-rt libraries llvm-svn: 191747
2013-10-01 12:52:15 +00:00
[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)
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" Clang relies on existence of certain symbols that are normally provided by crtbegin.o/crtend.o. However, LLVM does not currently provide implementation of these files, instead relying on either libgcc or implementations provided as part of the system. This change provides an initial implementation of crtbegin.o/crtend.o that can be used on system that don't provide crtbegin.o/crtend.o as part of their C library. Differential Revision: https://reviews.llvm.org/D28791 llvm-svn: 359591
2019-04-30 18:13:22 +00:00
option(COMPILER_RT_BUILD_CRT "Build crtbegin.o/crtend.o" ON)
mark_as_advanced(COMPILER_RT_BUILD_CRT)
Fix include guard and properly order __deregister_frame_info. Summary: This patch fixes two problems with the crtbegin.c as written: 1. In do_init, register_frame_info is not guarded by a #define, but in do_fini, deregister_frame_info is guarded by #ifndef CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not defined, frames are registered but then never deregistered. The frame registry mechanism builds a linked-list from the .so's static variable do_init.object, and when the .so is unloaded, this memory becomes invalid and should be deregistered. Further, libgcc's crtbegin treats the frame registry as independent from the initfini array mechanism. This patch fixes this by adding a new #define, "EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls register_frame_info, and then calls the binary's constructors. This allows constructors to safely use libunwind. However, do_fini calls deregister_frame_info and then calls the binary's destructors. This prevents destructors from safely using libunwind. This patch also switches that ordering, so that destructors can safely use libunwind. As it happens, this is a fairly common scenario for thread sanitizer.
2019-11-08 23:51:35 +00:00
option(COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY "Use eh_frame in crtbegin.o/crtend.o" ON)
mark_as_advanced(COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY)
[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)
[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 22:21:20 +00: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-24 04:14:56 +00: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)
[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
[asan] Add CMake hook to override shadow scale in compiler_rt Allow user to override shadow scale in compiler_rt by passing -DCOMPILER_RT_ASAN_SHADOW_SCALE=n to CMake. Propagate the override shadow scale value via a compiler define to compiler-rt and asan tests. Tests will use the define to partially disable unsupported tests. Set "-mllvm -asan-mapping-scale=<n>" for compiler_rt tests. Differential Revision: https://reviews.llvm.org/D39469 llvm-svn: 318038
2017-11-13 14:02:27 +00:00
set(COMPILER_RT_ASAN_SHADOW_SCALE ""
CACHE STRING "Override the shadow scale to be used in ASan runtime")
if (NOT COMPILER_RT_ASAN_SHADOW_SCALE STREQUAL "")
# Check that the shadow scale value is valid.
if (NOT (COMPILER_RT_ASAN_SHADOW_SCALE GREATER -1 AND
COMPILER_RT_ASAN_SHADOW_SCALE LESS 8))
message(FATAL_ERROR "
Invalid ASan Shadow Scale '${COMPILER_RT_ASAN_SHADOW_SCALE}'.")
endif()
set(COMPILER_RT_ASAN_SHADOW_SCALE_LLVM_FLAG
-mllvm -asan-mapping-scale=${COMPILER_RT_ASAN_SHADOW_SCALE})
set(COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION
ASAN_SHADOW_SCALE=${COMPILER_RT_ASAN_SHADOW_SCALE})
set(COMPILER_RT_ASAN_SHADOW_SCALE_FLAG
-D${COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION})
endif()
[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 18:33:49 +00: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)
[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
load_llvm_config()
[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.
set_target_properties(intrinsics_gen PROPERTIES FOLDER "Compiler-RT Misc")
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 14:52:23 +00: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 14:52:23 +00: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 14:52:23 +00: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 20:03:13 +00: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 17:23:26 +00: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 09:52:44 +00: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 21:10:17 +00: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)
Enable sanitizer tests (check-sanitizer, check-asan) on Windows llvm-svn: 208701
2014-05-13 14:25:49 +00:00
# We support running instrumented tests when we're not cross compiling
# and target a UNIX-like system or Windows.
# We can run tests on Android even when we are cross-compiling.
compiler-rt: add support for mingw-w64 in builtins The is so that we can avoid using libgcc and use compiler-rt with mingw-w64. Related driver patch http://reviews.llvm.org/D11077 I have tested this with mingw-w64 and everything seems to be in order. I also sent this patch to the mingw-w64 mailing list for them to look at. Patch by Martell Malone. Differential Revision: http://reviews.llvm.org/D11085 llvm-svn: 242539
2015-07-17 16:23:05 +00:00
if(("${CMAKE_HOST_SYSTEM}" STREQUAL "${CMAKE_SYSTEM}" AND (UNIX OR WIN32)) OR ANDROID
Enable CAN_EXECUTE_TESTS if an EMULATOR is provided llvm-svn: 208745
2014-05-14 00:36:15 +00:00
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 06:04:38 +00: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-31 03:19:39 +00: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] 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
if (APPLE OR CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
set(${var}_LIBNAME "libc++")
set(${var}_SYSTEM 1)
elseif (FUCHSIA)
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.
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.
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
[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)
if (FUCHSIA)
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 18:09:29 +00: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 22:25:05 +00: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] 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)
if (FUCHSIA)
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] 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
[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()
[CMake] Check for C++14 instead of C++11 Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should become `COMPILER_RT_HAS_STD_CXX14_FLAG`. I ran into this issue when replacing llvm::make_unique with std::make_unique in an X-ray unit test. We are correctly passing `-std=c++14`, but this got overwritten further down the invocation by the compiler-rt flags. Given that this unit test is using LLVM headers, this is bound to break sooner than later, regardless of my change. Differential revision: https://reviews.llvm.org/D66271 llvm-svn: 368960
2019-08-15 04:42:15 +00:00
append_string_if(COMPILER_RT_HAS_STD_CXX14_FLAG -std=c++14 CMAKE_CXX_FLAGS)
[CMake] Build compiler-rt libraries with -std=c++11 llvm-svn: 204145
2014-03-18 12:49:22 +00:00
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 21:53:49 +00: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 05:57:02 +00: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-05 03:22:28 +00: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 05:57:02 +00: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 22:25:41 +00: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 09:55:34 +00: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 22:25:41 +00: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 09:55:34 +00: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 22:25:41 +00: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 15:42:12 +00: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)
CFI: Get check-cfi passing on Windows. Specifically: - Start using %expect_crash. - Provide an implementation of __ubsan::getDynamicTypeInfoFromVtable for the Microsoft C++ ABI. This is all that is needed for CFI diagnostics; UBSan's -fsanitize=vptr also requires an implementation of __ubsan::checkDynamicType. - Build the sanitizer runtimes against the release version of the C runtime, even in debug builds. - Accommodate demangling differences in tests. Differential Revision: http://reviews.llvm.org/D11029 llvm-svn: 241745
2015-07-08 22:10:34 +00:00
# Replace the /M[DT][d] flags with /MT, and strip any definitions of _DEBUG,
# which cause definition mismatches at link time.
[ASan/Win] Fix PR18987: warning about overriding '/MD' with '/MT' llvm-svn: 215435
2014-08-12 09:44:56 +00:00
# FIXME: In fact, sanitizers should support both /MT and /MD, see PR20214.
[CMake] Fix PR18987: discard /MD flag if we're adding /MT llvm-svn: 202472
2014-02-28 08:04:30 +00:00
if(COMPILER_RT_HAS_MT_FLAG)
Change all of the build flags to switch /MD and /MDd into /MT, instead of just some of the targets. Fixes PR21241. llvm-svn: 220506
2014-10-23 20:24:00 +00:00
foreach(flag_var
[CMake] Add partial support for MSVC in compiler-rt builtins, by Roman Shirokiy. This enables MSVC build of complex number arithmetic compiler-rt builtins. Differential Revision: http://reviews.llvm.org/D17452 llvm-svn: 261432
2016-02-20 12:56:04 +00:00
CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO
Change all of the build flags to switch /MD and /MDd into /MT, instead of just some of the targets. Fixes PR21241. llvm-svn: 220506
2014-10-23 20:24:00 +00:00
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
CFI: Get check-cfi passing on Windows. Specifically: - Start using %expect_crash. - Provide an implementation of __ubsan::getDynamicTypeInfoFromVtable for the Microsoft C++ ABI. This is all that is needed for CFI diagnostics; UBSan's -fsanitize=vptr also requires an implementation of __ubsan::checkDynamicType. - Build the sanitizer runtimes against the release version of the C runtime, even in debug builds. - Accommodate demangling differences in tests. Differential Revision: http://reviews.llvm.org/D11029 llvm-svn: 241745
2015-07-08 22:10:34 +00:00
string(REGEX REPLACE "/M[DT]d" "/MT" ${flag_var} "${${flag_var}}")
string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")
string(REGEX REPLACE "/D_DEBUG" "" ${flag_var} "${${flag_var}}")
Change all of the build flags to switch /MD and /MDd into /MT, instead of just some of the targets. Fixes PR21241. llvm-svn: 220506
2014-10-23 20:24:00 +00:00
endforeach()
[CMake] Fix PR18987: discard /MD flag if we're adding /MT llvm-svn: 202472
2014-02-28 08:04:30 +00:00
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_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
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 17:29:41 +00:00
if(CMAKE_CXX_COMPILER_ID MATCHES Clang)
sanitizer_common: fix 32-bit build https://reviews.llvm.org/D105716 enabled thread safety annotations, and that broke 32-bit build: https://green.lab.llvm.org/green/job/lldb-cmake/33604/consoleFull#-77815080549ba4694-19c4-4d7e-bec5-911270d8a58c 1. Enable thread-safety analysis in unit tests (this catches the breakage even in 64-bit mode). 2. Add NO_THREAD_SAFETY_ANALYSIS to sanitizer_allocator_primary32.h to unbreak the build. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D105808
2021-07-12 11:57:14 +00:00
list(APPEND THREAD_SAFETY_FLAGS
sanitizers: turn thread-safety errors into warnings There were 2 issues reported on https://reviews.llvm.org/D105716: 1. FreeBSD phtread.h is annotated with thread-safety attributes and this causes errors in gtest headers. 2. If sanitizers are compiled with an older versions of clang (which supports the annotations, but has some false positives in analysis not present in later versions of clang), compilation fails with errors. Switch the errors to warnings by default. Some CI bots enable COMPILER_RT_ENABLE_WERROR, which should turn these warnings back into errors. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D107826
2021-08-10 14:16:32 +00:00
"-Wthread-safety"
"-Wthread-safety-reference"
"-Wthread-safety-beta"
sanitizer_common: fix 32-bit build https://reviews.llvm.org/D105716 enabled thread safety annotations, and that broke 32-bit build: https://green.lab.llvm.org/green/job/lldb-cmake/33604/consoleFull#-77815080549ba4694-19c4-4d7e-bec5-911270d8a58c 1. Enable thread-safety analysis in unit tests (this catches the breakage even in 64-bit mode). 2. Add NO_THREAD_SAFETY_ANALYSIS to sanitizer_allocator_primary32.h to unbreak the build. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D105808
2021-07-12 11:57:14 +00:00
)
list(APPEND SANITIZER_COMMON_CFLAGS ${THREAD_SAFETY_FLAGS})
sanitizer_common: Fix build for tests It turns out that COMPILER_RT_TEST_COMPILER_CFLAGS is actually a string that is being appended to and not a list. Therefore, append the thread-safety flags to the string. Because CMake separates list elements by ';' when turning into a string, also substitute ';' with ' '. Reviewed By: hctim Differential Revision: https://reviews.llvm.org/D105829
2021-07-12 22:39:17 +00:00
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 17:29:41 +00:00
endif()
[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)
sanitizers: compile with -O1 under debug Tsan's check_memcpy.c test was disabled under debug because it failed. But it points to real issues and does not help to just disable it. I tried to enable it and see what fail and the first hit was default ctor for: struct ChainedOriginDepotDesc { u32 here_id; u32 prev_id; }; initializing these fields to 0's help partially, but compiler still emits memset before calling ctor. I did not try to see what's the next failure, because if it fails on such small structs, it won't be realistic to fix everything and keep working. Compile runtimes with -O1 under debug instead. It seems to fix all current failures. At least I run check-tsan under clang/gcc x debug/non-debug and all combinations passed. -O1 does not usually use too aggressive optimizations and sometimes even makes debugging easier because machine code is not exceedingly verbose. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107962
2021-08-12 13:43:09 +00: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()
[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 21:29:32 +00: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 17:37:29 +00: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)
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.
append_list_if(COMPILER_RT_HAS_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
[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 18:03:37 +00:00
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Fuchsia")
list(APPEND SANITIZER_COMMON_LINK_LIBS zircon)
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 18:03:37 +00: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-21 02:10:50 +00: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-31 03:19:39 +00: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 18:25:52 +00: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-31 03:19:39 +00: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})
[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(append_libcxx_libs var)
if (${var}_INTREE)
[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
if (SANITIZER_USE_STATIC_LLVM_UNWINDER AND (TARGET unwind_static OR HAVE_LIBUNWIND))
[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 ${var}_LIBRARIES unwind_static)
[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
elseif (TARGET unwind_shared OR HAVE_LIBUNWIND)
[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 ${var}_LIBRARIES unwind_shared)
[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()
[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
if (SANITIZER_USE_STATIC_CXX_ABI AND (TARGET cxxabi_static OR HAVE_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 ${var}_LIBRARIES cxxabi_static)
[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
elseif (TARGET cxxabi_shared OR HAVE_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 ${var}_LIBRARIES cxxabi_shared)
[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()
[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_LIBCXX c++ ${var}_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()
[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
endmacro()
if (SANITIZER_CXX_ABI_LIBNAME STREQUAL "libc++")
append_libcxx_libs(SANITIZER_CXX_ABI)
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++")
append_libcxx_libs(SANITIZER_TEST_CXX)
elseif (SANITIZER_TEST_CXX_LIBNAME STREQUAL "libstdc++")
append_list_if(COMPILER_RT_HAS_LIBSTDCXX stdc++ 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()
[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-31 03:19:39 +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.
[NFC][CMake] Move some COMPILER_RT variables setup Part of D88922
2020-10-30 23:16:09 +00:00
string(REPLACE " " ";" COMPILER_RT_UNITTEST_CFLAGS "${COMPILER_RT_TEST_COMPILER_CFLAGS}")
set(COMPILER_RT_UNITTEST_LINK_FLAGS ${COMPILER_RT_UNITTEST_CFLAGS})
# Unittests support.
set(COMPILER_RT_GTEST_PATH ${LLVM_MAIN_SRC_DIR}/utils/unittest/googletest)
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.
set(COMPILER_RT_GMOCK_PATH ${LLVM_MAIN_SRC_DIR}/utils/unittest/googlemock)
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 14:56:36 +00: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 23:16:09 +00: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)
if(MSVC)
# gtest use a lot of stuff marked as deprecated on Windows.
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.
Fix CMake/MSVC when compiler-rt and llvm are built separately Summary: For some reason CMake can't find the `append` macro if LLVM is built separately and imported via `LLVM_CONFIG_PATH`. Patch by Loo Rong Jie Reviewers: rnk, vitalybuka Reviewed By: rnk, vitalybuka Subscribers: dberris, mgorny, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43458 llvm-svn: 327876
2018-03-19 18:22:35 +00:00
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} /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()
[AIX][compiler-rt] Use the AR/ranlib mode flag for 32-bit and 64-bit mode since we will be building both 32-bit and 64-bit compiler-rt builtins from a single configuration. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87113
2020-01-02 15:11:59 +00:00
if(${CMAKE_SYSTEM_NAME} MATCHES "AIX")
set(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> -X32_64 qc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> -X32_64 qc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_APPEND "<CMAKE_AR> -X32_64 q <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_APPEND "<CMAKE_AR> -X32_64 q <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_FINISH "<CMAKE_RANLIB> -X32_64 <TARGET>")
set(CMAKE_CXX_ARCHIVE_FINISH "<CMAKE_RANLIB> -X32_64 <TARGET>")
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)
if(COMPILER_RT_USE_LIBCXX)
[compiler-rt] Don't use libcxx if it's not enabled by LLVM_ENABLE_PROJECTS This fixes sanitizer-x86_64-linux-fuzzer which switched to new layout and not it can't link as libcxx is always there. We should support and tests libcxx but still it was unexpected that libfuzzer ignored LLVM_ENABLE_PROJECTS_USED. llvm-svn: 370153
2019-08-28 02:41:14 +00:00
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})
else()
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()
[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
endif()
Move MSan lit-tests under test/msan llvm-svn: 201412
2014-02-14 13:02:58 +00:00
Revert "Determine up front which projects are enabled." This was intended to be a generic CMake solution to a problem shared across several projects. It turns out it doesn't interact very well certain CMake configurations, and furthermore the "problem" is actually not a problem, as the problematic code is never executed to begin with. So this really isn't solving anything. llvm-svn: 313191
2017-09-13 20:49:25 +00:00
set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/tools/lld)
if(EXISTS ${COMPILER_RT_LLD_PATH}/ AND LLVM_TOOL_LLD_BUILD)
set(COMPILER_RT_HAS_LLD TRUE)
else()
set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/../lld)
if(EXISTS ${COMPILER_RT_LLD_PATH}/ AND LLVM_TOOL_LLD_BUILD)
set(COMPILER_RT_HAS_LLD TRUE)
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-04 00:10:35 +00: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)
if(COMPILER_RT_HAS_FUSE_LD_LLD_FLAG)
set(COMPILER_RT_HAS_GNU_VERSION_SCRIPT_COMPAT FALSE)
endif()
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-04 00:10:35 +00: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
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)
Move shared configs for lit test suites to test/ and unittests/ directories llvm-svn: 201399
2014-02-14 11:00:07 +00:00
add_subdirectory(unittests)
[CMake] If COMPILER_RT_INCLUDE_TESTS is off we shouldn't include the root test directory. llvm-svn: 247606
2015-09-14 19:54:12 +00:00
add_subdirectory(test)
[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 08:39:50 +00: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-07 00:38:26 +00: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)
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()
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