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

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

394 lines
16 KiB
CMake
Raw Normal View History

[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
if (NOT IS_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/../libcxx")
message(FATAL_ERROR "libunwind requires being built in a monorepo layout with libcxx available")
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
#===============================================================================
Revert test commit. llvm-svn: 244297
2015-08-07 07:31:37 +08:00
# Setup Project
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
#===============================================================================
[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 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Reland "[CMake][libunwind] Use -nodefaultlibs for CMake checks" This is a reland of commit r299796. Turned out that we need gcc_s or compiler-rt on ARM when checking the support for -funwind-tables which creates a dependency on __aeabi_unwind_cpp_pr0 symbol that's provided by the compiler runtime. Differential Revision: https://reviews.llvm.org/D31858 llvm-svn: 300020
2017-04-12 10:28:07 +08:00
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${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 08:37:20 +08:00
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules"
Reland "[CMake][libunwind] Use -nodefaultlibs for CMake checks" This is a reland of commit r299796. Turned out that we need gcc_s or compiler-rt on ARM when checking the support for -funwind-tables which creates a dependency on __aeabi_unwind_cpp_pr0 symbol that's provided by the compiler runtime. Differential Revision: https://reviews.llvm.org/D31858 llvm-svn: 300020
2017-04-12 10:28:07 +08:00
${CMAKE_MODULE_PATH}
)
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
set(LIBUNWIND_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LIBUNWIND_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
set(LIBUNWIND_LIBCXX_PATH "${CMAKE_CURRENT_LIST_DIR}/../libcxx" CACHE PATH
"Specify path to libc++ source.")
[CMake] Use find_package(LLVM) instead of LLVMConfig This addresses an issues introduced in r362047. Differential Revision: https://reviews.llvm.org/D62640 llvm-svn: 362065
2019-05-30 15:34:39 +08:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBUNWIND_STANDALONE_BUILD)
[libunwind] Try to add --unwindlib=none while configuring and building libunwind If Clang is set up to link directly against libunwind (via the --unwindlib option, or the corresponding builtin default option), configuring libunwind will fail while bootstrapping (before the initial libunwind is built), because every cmake test will fail due to -lunwind not being found, and linking the shared library will fail similarly. Check if --unwindlib=none is supported, and add it in that case. Using check_c_compiler_flag on its own doesn't work, because that only adds the tested flag to the compilation command, and if -lunwind is missing, the linking step would still fail - instead try adding it to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work. This avoids having to pass --unwindlib=none while building libunwind. Differential Revision: https://reviews.llvm.org/D112126
2021-09-11 03:14:48 +08:00
# We may have an incomplete toolchain - do language support tests without
# linking.
include(EnableLanguageNolink)
project(libunwind LANGUAGES NONE)
llvm_enable_language_nolink(C CXX ASM)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
set(PACKAGE_NAME libunwind)
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
set(PACKAGE_VERSION 14.0.0git)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
Update to new lists.llvm.org llvm-svn: 244005
2015-08-05 12:01:47 +08:00
set(PACKAGE_BUGREPORT "llvm-bugs@lists.llvm.org")
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
# Add the CMake module path of libcxx so we can reuse HandleOutOfTreeLLVM.cmake
set(LIBUNWIND_LIBCXX_CMAKE_PATH "${LIBUNWIND_LIBCXX_PATH}/cmake/Modules")
list(APPEND CMAKE_MODULE_PATH "${LIBUNWIND_LIBCXX_CMAKE_PATH}")
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
# In a standalone build, we don't have llvm to automatically generate the
# llvm-lit script for us. So we need to provide an explicit directory that
# the configurator should write the script into.
set(LIBUNWIND_STANDALONE_BUILD 1)
set(LLVM_LIT_OUTPUT_DIR "${LIBUNWIND_BINARY_DIR}/bin")
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
# Find the LLVM sources and simulate LLVM CMake options.
include(HandleOutOfTreeLLVM)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
else()
set(LLVM_LIT "${CMAKE_SOURCE_DIR}/utils/lit/lit.py")
endif()
#===============================================================================
# Setup CMake Options
#===============================================================================
[CMake] Include CMakeDependentOption in libunwind This should resolve the breakage introduced in r337867 which introduced the use of cmake_dependent_option without include the necessary file. llvm-svn: 337868
2018-07-25 07:42:51 +08:00
include(CMakeDependentOption)
Reland "[CMake][libunwind] Use -nodefaultlibs for CMake checks" This is a reland of commit r299796. Turned out that we need gcc_s or compiler-rt on ARM when checking the support for -funwind-tables which creates a dependency on __aeabi_unwind_cpp_pr0 symbol that's provided by the compiler runtime. Differential Revision: https://reviews.llvm.org/D31858 llvm-svn: 300020
2017-04-12 10:28:07 +08:00
include(HandleCompilerRT)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
# Define options.
[libunwind] Allow target flags to affect CMake configuration tests Summary: This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20889 llvm-svn: 271458
2016-06-02 09:02:10 +08:00
option(LIBUNWIND_BUILD_32_BITS "Build 32 bit libunwind" ${LLVM_BUILD_32_BITS})
[libunwind] Support stack unwind in CET environment Control-flow Enforcement Technology (CET), published by Intel, introduces shadow stack feature aiming to ensure a return from a function is directed to where the function was called. In a CET enabled system, each function call will push return address into normal stack and shadow stack, when the function returns, the address stored in shadow stack will be popped and compared with the return address, program will fail if the 2 addresses don't match. In exception handling, the control flow may skip some stack frames and we must adjust shadow stack to avoid violating CET restriction. In order to achieve this, we count the number of stack frames skipped and adjust shadow stack by this number before jumping to landing pad. Reviewed By: hjl.tools, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D105968 Signed-off-by: gejin <ge.jin@intel.com>
2021-08-26 16:20:38 +08:00
option(LIBUNWIND_ENABLE_CET "Build libunwind with CET enabled." OFF)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
option(LIBUNWIND_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
option(LIBUNWIND_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
option(LIBUNWIND_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
option(LIBUNWIND_ENABLE_SHARED "Build libunwind as a shared library." ON)
Allow building both shared and static library This change allows building both shared and static version of libunwind in a single build, sharing object files between both versions. Differential Revision: https://reviews.llvm.org/D23233 llvm-svn: 278067
2016-08-09 06:55:48 +08:00
option(LIBUNWIND_ENABLE_STATIC "Build libunwind as a static library." ON)
[libunwind] Disable cross-unwinding by default. Cross unwinding requires larger sizes for unw_context_t and unw_cursor_t buffers (large enough to hold the VRS of any architecture). This is not desirable for the most common situation where libunwind is used for native unwinding only. This patch makes native unwinding the default build configuration. This will start testing the tigher (compile-time) bounds of unw_context_t and unw_cursor_t buffers for each architecture. Change-Id: Ic61c476a75603ca4812959c233cfe56f83dc0b00 llvm-svn: 270972
2016-05-27 16:29:27 +08:00
option(LIBUNWIND_ENABLE_CROSS_UNWINDING "Enable cross-platform unwinding support." OFF)
[libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional These registers are only available on a limited set of ARM targets (those based on XScale). Other targets should not have to pay the cost of these. This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size. Differential revision: http://reviews.llvm.org/D21991 Reviewers: bcraig, compnerd Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7 llvm-svn: 274744
2016-07-07 18:55:39 +08:00
option(LIBUNWIND_ENABLE_ARM_WMMX "Enable unwinding support for ARM WMMX registers." OFF)
[libunwind] Add support for a single-threaded libunwind build The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder have a couple of pthread dependencies. This patch makes it possible to build the whole of libunwind for a single-threaded environment. Reviewers: compnerd Differential revision: https://reviews.llvm.org/D24984 llvm-svn: 282575
2016-09-28 18:57:15 +08:00
option(LIBUNWIND_ENABLE_THREADS "Build libunwind with threading support." ON)
Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread library use weak symbols. This option allows libpthread to be a weak dependency rather than a hard one. Differential Revision: https://reviews.llvm.org/D60285 llvm-svn: 360610
2019-05-14 02:45:03 +08:00
option(LIBUNWIND_WEAK_PTHREAD_LIB "Use weak references to refer to pthread functions." OFF)
Reland "[CMake][libunwind] Use -nodefaultlibs for CMake checks" This is a reland of commit r299796. Turned out that we need gcc_s or compiler-rt on ARM when checking the support for -funwind-tables which creates a dependency on __aeabi_unwind_cpp_pr0 symbol that's provided by the compiler runtime. Differential Revision: https://reviews.llvm.org/D31858 llvm-svn: 300020
2017-04-12 10:28:07 +08:00
option(LIBUNWIND_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
[libunwind] Add sphinx docs https://reviews.llvm.org/D31375 llvm-svn: 298922
2017-03-28 23:21:43 +08:00
option(LIBUNWIND_INCLUDE_DOCS "Build the libunwind documentation." ${LLVM_INCLUDE_DOCS})
[libunwind][cmake] Add an option to enable/disable tests Reviewed By: ldionne, compnerd Differential Revision: https://reviews.llvm.org/D96342
2021-02-13 18:49:47 +08:00
option(LIBUNWIND_INCLUDE_TESTS "Build the libunwind tests." ${LLVM_INCLUDE_TESTS})
[libunwind] Provide a way to set '_LIBUNWIND_IS_BAREMETAL' through cmake. Libunwind uses _LIBUNWIND_IS_BAREMETAL in a lot of places but there is no cmake variable to set it. This patch adds such a variable. It is quite like what LIBCXXABI_BAREMETAL does in libcxxabi. Reviewed By: compnerd, #libunwind Differential Revision: https://reviews.llvm.org/D84759
2020-07-29 18:39:41 +08:00
option(LIBUNWIND_IS_BAREMETAL "Build libunwind for baremetal targets." OFF)
Default to disabling the libunwind frameheader cache. Although it works fine with glibc, as currently implemented the frameheader cache is incompatible with certain platforms with slightly different locking semantics inside dl_iterate_phdr. Therefore only enable it when it is turned on explicitly with a configure-time option. Differential Revision: https://reviews.llvm.org/D86163
2020-08-19 03:05:07 +08:00
option(LIBUNWIND_USE_FRAME_HEADER_CACHE "Cache frame headers for unwinding. Requires locking dl_iterate_phdr." OFF)
[libunwind] LIBUNWIND_REMEMBER_HEAP_ALLOC to cmake. Missed it originally in https://reviews.llvm.org/D85005. Reviewed By: gargaroff Differential Revision: https://reviews.llvm.org/D91182
2020-11-11 17:58:41 +08:00
option(LIBUNWIND_REMEMBER_HEAP_ALLOC "Use heap instead of the stack for .cfi_remember_state." OFF)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[CMake] Allow overriding lib dir suffix independently from LLVM This matches the options already supported by libc++ and libc++abi. Differential Revision: https://reviews.llvm.org/D36383 llvm-svn: 310327
2017-08-08 08:37:59 +08:00
set(LIBUNWIND_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
"Define suffix of library directory name (32/64)")
[libunwind][CMake] Provide option to disable instalation of the library This is useful in cases where we only build static library and libunwind.a is combined with libc++abi.a into a single archive in which case we don't want to have libunwind.a installed separately. The same option is already provided by libcxx CMake build. This change also adds the install-unwind target for consistency with the libcxxabi and libcxx CMake build. Differential Revision: https://reviews.llvm.org/D40195 llvm-svn: 318569
2017-11-18 07:29:46 +08:00
option(LIBUNWIND_INSTALL_LIBRARY "Install the libunwind library." ON)
[CMake] Option to control whether shared/static library is installed Currently it's only possible to control whether shared or static library build of libc++, libc++abi and libunwind is enabled or disabled and whether to install everything we've built or not. However, it'd be useful to have more fine grained control, e.g. when static libraries are merged together into libc++.a we don't need to install libc++abi.a and libunwind.a. This change adds this option. Differential Revision: https://reviews.llvm.org/D49573 llvm-svn: 337867
2018-07-25 07:27:51 +08:00
cmake_dependent_option(LIBUNWIND_INSTALL_STATIC_LIBRARY
"Install the static libunwind library." ON
"LIBUNWIND_ENABLE_STATIC;LIBUNWIND_INSTALL_LIBRARY" OFF)
cmake_dependent_option(LIBUNWIND_INSTALL_SHARED_LIBRARY
"Install the shared libunwind library." ON
"LIBUNWIND_ENABLE_SHARED;LIBUNWIND_INSTALL_LIBRARY" OFF)
[runtimes] Properly handle the sysroot/triple/gcc-toolchain In 395271a, I simplified how we handled the target triple for the runtimes. However, in doing so, we stopped considering the default in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE (which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified. This commit fixes that problem and also refactors the code so that it's easy to see what the default value is. The fact that nobody seems to have been broken by this makes me think that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the triple -- but it should still work. Differential Revision: https://reviews.llvm.org/D111672
2021-10-13 03:59:08 +08:00
if(CMAKE_CXX_COMPILER_TARGET)
set(LIBUNWIND_DEFAULT_TARGET_TRIPLE "${CMAKE_CXX_COMPILER_TARGET}")
else()
set(LIBUNWIND_DEFAULT_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
endif()
set(LIBUNWIND_TARGET_TRIPLE "${LIBUNWIND_DEFAULT_TARGET_TRIPLE}" CACHE STRING "Target triple for cross compiling.")
set(LIBUNWIND_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}" CACHE PATH "GCC toolchain for cross compiling.")
set(LIBUNWIND_SYSROOT "${CMAKE_SYSROOT}" CACHE PATH "Sysroot for cross compiling.")
[libunwind] Permit additional compiler and linker flags to be passed to tests. Summary: This is done via new LIBUNWIND_TEST_COMPILER_FLAGS and LIBUNWIND_TEST_LINKER_FLAGS variables. Reviewed By: sdardis Differential Revision: https://reviews.llvm.org/D43585 llvm-svn: 326223
2018-02-28 02:40:04 +08:00
set(LIBUNWIND_TEST_LINKER_FLAGS "" CACHE STRING
"Additional linker flags for test programs.")
set(LIBUNWIND_TEST_COMPILER_FLAGS "" CACHE STRING
"Additional compiler flags for test programs.")
[libunwind] Take 2: Use the from-scratch testing configuration by default Summary: This commit switches libunwind from using the complicated logic in libc++'s testing configuration to a from-scratch configuration. I tried to make sure that all cases that were handled in the old config were handled by this one too, so hopefully this shouldn't break anyone. However, if you encounter issues with this change, please let me know and feel free to revert if I don't reply quickly. This change was engineered to be easily revertable. This commit is a re-application of 5a8ad80b6fa5, which was reverted in 070a2ddcb665 because it broke the Bootstrapping build. This has now been addressed by tweaking the from-scratch config. Differential Revision: https://reviews.llvm.org/D112082
2021-10-13 02:10:02 +08:00
if (LIBUNWIND_ENABLE_SHARED)
set(LIBUNWIND_DEFAULT_TEST_CONFIG "llvm-libunwind-shared.cfg.in")
else()
set(LIBUNWIND_DEFAULT_TEST_CONFIG "llvm-libunwind-static.cfg.in")
endif()
set(LIBUNWIND_TEST_CONFIG "${LIBUNWIND_DEFAULT_TEST_CONFIG}" CACHE STRING
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-30 03:26:05 +08:00
"The path to the Lit testing configuration to use when running the tests.
[libunwind] Add a from-scratch config for running libunwind tests Running tests for libunwind is a lot simpler than running tests for libc++, so a simple Lit config file is sufficient. The benefit is that we disentangle the libunwind test configuration from the libc++ and libc++abi test configuration. The setup was too complicated, which led to some bugs (notably we were running against the system libunwind on Apple platforms). Differential Revision: https://reviews.llvm.org/D111664
2021-10-13 00:46:21 +08:00
If a relative path is provided, it is assumed to be relative to '<monorepo>/libunwind/test/configs'.")
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-30 03:26:05 +08:00
if (NOT IS_ABSOLUTE "${LIBUNWIND_TEST_CONFIG}")
[libunwind] Add a from-scratch config for running libunwind tests Running tests for libunwind is a lot simpler than running tests for libc++, so a simple Lit config file is sufficient. The benefit is that we disentangle the libunwind test configuration from the libc++ and libc++abi test configuration. The setup was too complicated, which led to some bugs (notably we were running against the system libunwind on Apple platforms). Differential Revision: https://reviews.llvm.org/D111664
2021-10-13 00:46:21 +08:00
set(LIBUNWIND_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/configs/${LIBUNWIND_TEST_CONFIG}")
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-30 03:26:05 +08:00
endif()
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
set(LIBUNWIND_TEST_PARAMS "" CACHE STRING
"A list of parameters to run the Lit test suite with.")
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Allow building both shared and static library This change allows building both shared and static version of libunwind in a single build, sharing object files between both versions. Differential Revision: https://reviews.llvm.org/D23233 llvm-svn: 278067
2016-08-09 06:55:48 +08:00
if (NOT LIBUNWIND_ENABLE_SHARED AND NOT LIBUNWIND_ENABLE_STATIC)
message(FATAL_ERROR "libunwind must be built as either a shared or static library.")
endif()
[libunwind] Support stack unwind in CET environment Control-flow Enforcement Technology (CET), published by Intel, introduces shadow stack feature aiming to ensure a return from a function is directed to where the function was called. In a CET enabled system, each function call will push return address into normal stack and shadow stack, when the function returns, the address stored in shadow stack will be popped and compared with the return address, program will fail if the 2 addresses don't match. In exception handling, the control flow may skip some stack frames and we must adjust shadow stack to avoid violating CET restriction. In order to achieve this, we count the number of stack frames skipped and adjust shadow stack by this number before jumping to landing pad. Reviewed By: hjl.tools, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D105968 Signed-off-by: gejin <ge.jin@intel.com>
2021-08-26 16:20:38 +08:00
if (LIBUNWIND_ENABLE_CET AND MSVC)
message(FATAL_ERROR "libunwind CET support is not available for MSVC!")
endif()
Add status/warning message for 32 bit builds llvm-svn: 271462
2016-06-02 09:19:52 +08:00
# Check that we can build with 32 bits if requested.
if (CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32)
if (LIBUNWIND_BUILD_32_BITS AND NOT LLVM_BUILD_32_BITS) # Don't duplicate the output from LLVM
message(STATUS "Building 32 bits executables and libraries.")
endif()
elseif(LIBUNWIND_BUILD_32_BITS)
message(FATAL_ERROR "LIBUNWIND_BUILD_32_BITS=ON is not supported on this platform.")
endif()
[libunwind] unw_* alias fixes for ELF and Mach-O Rename the CMake option, LIBUNWIND_HERMETIC_STATIC_LIBRARY, to LIBUNWIND_HIDE_SYMBOLS. Rename the C macro define, _LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS, to _LIBUNWIND_HIDE_SYMBOLS, because now the macro adds a .hidden directive rather than merely suppress visibility annotations. For ELF, when LIBUNWIND_HIDE_SYMBOLS is enabled, mark unw_getcontext as hidden. This symbol is the only one defined using src/assembly.h's WEAK_ALIAS macro. Other unw_* weak aliases are defined in C++ and are already hidden. Mach-O doesn't support weak aliases, so remove .weak_reference and weak_import. When LIBUNWIND_HIDE_SYMBOLS is enabled, output .private_extern for the unw_* aliases. In assembly.h, add missing SYMBOL_NAME macro invocations, which are used to prefix symbol names with '_' on some targets. Fixes PR46709. Reviewed By: #libunwind, phosek, compnerd, steven_wu Differential Revision: https://reviews.llvm.org/D93003
2021-02-23 08:35:38 +08:00
option(LIBUNWIND_HIDE_SYMBOLS
[libunwind] Support building hermetic static library This is useful when the static libunwind library is being linked into shared libraries that may be used in with other shared libraries that use different unwinder. We want to avoid avoid exporting libunwind symbols in those cases. This achieved by a new CMake option which can be enabled by libunwind vendors as needed. The same CMake option has already been added to libc++ and libc++abi in D55404 and D56026. Differential Revision: https://reviews.llvm.org/D57107 llvm-svn: 352559
2019-01-30 07:01:08 +08:00
"Do not export any symbols from the static library." OFF)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
#===============================================================================
# Configure System
#===============================================================================
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
${CMAKE_MODULE_PATH})
Revert "Revert "Support for multiarch runtimes layout"" This reverts commit r336005 that was accidentally committed. llvm-svn: 336012
2018-06-30 04:27:40 +08:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
[libcxx] Stop using use c++ subdirectory for libc++ library The new layout more closely matches the layout used by other compilers. This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled. Differential Revision: https://reviews.llvm.org/D100869
2021-04-17 12:33:18 +08:00
set(LIBUNWIND_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
"Path where built libunwind libraries should be installed.")
[runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs) Differential Revision: https://reviews.llvm.org/D107892
2021-08-11 18:44:06 +08:00
set(LIBUNWIND_INSTALL_RUNTIME_DIR bin CACHE PATH
"Path where built libunwind runtime libraries should be installed.")
[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
2019-05-23 05:08:33 +08:00
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBUNWIND_LIBRARY_DIR /${LIBUNWIND_LIBDIR_SUBDIR})
string(APPEND LIBUNWIND_INSTALL_LIBRARY_DIR /${LIBUNWIND_LIBDIR_SUBDIR})
endif()
Revert "Revert "Support for multiarch runtimes layout"" This reverts commit r336005 that was accidentally committed. llvm-svn: 336012
2018-06-30 04:27:40 +08:00
elseif(LLVM_LIBRARY_OUTPUT_INTDIR)
[CMake] Set library dir to be LLVM's intermediate output dir This matches the behavior of libc++abi and libc++ and ensures that we get a working toolchain when building libunwind as part of LLVM. Differential Revision: https://reviews.llvm.org/D34375 llvm-svn: 308380
2017-07-19 05:30:18 +08:00
set(LIBUNWIND_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LIBUNWIND_LIBDIR_SUFFIX} CACHE PATH
"Path where built libunwind libraries should be installed.")
[runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs) Differential Revision: https://reviews.llvm.org/D107892
2021-08-11 18:44:06 +08:00
set(LIBUNWIND_INSTALL_RUNTIME_DIR bin CACHE PATH
"Path where built libunwind runtime libraries should be installed.")
[CMake] Set library dir to be LLVM's intermediate output dir This matches the behavior of libc++abi and libc++ and ensures that we get a working toolchain when building libunwind as part of LLVM. Differential Revision: https://reviews.llvm.org/D34375 llvm-svn: 308380
2017-07-19 05:30:18 +08:00
else()
[CMake] Allow overriding lib dir suffix independently from LLVM This matches the options already supported by libc++ and libc++abi. Differential Revision: https://reviews.llvm.org/D36383 llvm-svn: 310327
2017-08-08 08:37:59 +08:00
set(LIBUNWIND_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBUNWIND_LIBDIR_SUFFIX})
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LIBUNWIND_LIBDIR_SUFFIX} CACHE PATH
"Path where built libunwind libraries should be installed.")
[runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs) Differential Revision: https://reviews.llvm.org/D107892
2021-08-11 18:44:06 +08:00
set(LIBUNWIND_INSTALL_RUNTIME_DIR bin CACHE PATH
"Path where built libunwind runtime libraries should be installed.")
[CMake] Set library dir to be LLVM's intermediate output dir This matches the behavior of libc++abi and libc++ and ensures that we get a working toolchain when building libunwind as part of LLVM. Differential Revision: https://reviews.llvm.org/D34375 llvm-svn: 308380
2017-07-19 05:30:18 +08:00
endif()
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LIBUNWIND_LIBRARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIBUNWIND_LIBRARY_DIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LIBUNWIND_LIBRARY_DIR})
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libunwind] Allow target flags to affect CMake configuration tests Summary: This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20889 llvm-svn: 271458
2016-06-02 09:02:10 +08:00
set(LIBUNWIND_C_FLAGS "")
set(LIBUNWIND_CXX_FLAGS "")
set(LIBUNWIND_COMPILE_FLAGS "")
set(LIBUNWIND_LINK_FLAGS "")
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
# Include macros for adding and removing libunwind flags.
include(HandleLibunwindFlags)
#===============================================================================
# Setup Compiler Flags
#===============================================================================
[libunwind] Allow target flags to affect CMake configuration tests Summary: This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20889 llvm-svn: 271458
2016-06-02 09:02:10 +08:00
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
# Get required flags.
[libunwind] Allow target flags to affect CMake configuration tests Summary: This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20889 llvm-svn: 271458
2016-06-02 09:02:10 +08:00
add_target_flags_if(LIBUNWIND_BUILD_32_BITS "-m32")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
[libunwind] Try to add --unwindlib=none while configuring and building libunwind If Clang is set up to link directly against libunwind (via the --unwindlib option, or the corresponding builtin default option), configuring libunwind will fail while bootstrapping (before the initial libunwind is built), because every cmake test will fail due to -lunwind not being found, and linking the shared library will fail similarly. Check if --unwindlib=none is supported, and add it in that case. Using check_c_compiler_flag on its own doesn't work, because that only adds the tested flag to the compilation command, and if -lunwind is missing, the linking step would still fail - instead try adding it to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work. This avoids having to pass --unwindlib=none while building libunwind. Differential Revision: https://reviews.llvm.org/D112126
2021-09-11 03:14:48 +08:00
# Compiler tests may be failing if the compiler implicitly links in libunwind,
# which doesn't exist yet. This gets waived by --unwindlib=none
# later in config-ix below, but the tests for --target etc before that may
# be failing due to it. Only test compilation, not linking, for these
# tests here now.
set(CMAKE_TRY_COMPILE_TARGET_TYPE_ORIG ${CMAKE_TRY_COMPILE_TARGET_TYPE})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
if(LIBUNWIND_TARGET_TRIPLE)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--target=${LIBUNWIND_TARGET_TRIPLE}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
endif()
if(LIBUNWIND_GCC_TOOLCHAIN)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--gcc-toolchain=${LIBUNWIND_GCC_TOOLCHAIN}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
endif()
if(LIBUNWIND_SYSROOT)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--sysroot=${LIBUNWIND_SYSROOT}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
endif()
[libunwind] Try to add --unwindlib=none while configuring and building libunwind If Clang is set up to link directly against libunwind (via the --unwindlib option, or the corresponding builtin default option), configuring libunwind will fail while bootstrapping (before the initial libunwind is built), because every cmake test will fail due to -lunwind not being found, and linking the shared library will fail similarly. Check if --unwindlib=none is supported, and add it in that case. Using check_c_compiler_flag on its own doesn't work, because that only adds the tested flag to the compilation command, and if -lunwind is missing, the linking step would still fail - instead try adding it to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work. This avoids having to pass --unwindlib=none while building libunwind. Differential Revision: https://reviews.llvm.org/D112126
2021-09-11 03:14:48 +08:00
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE_ORIG})
[libunwind] Allow target flags to affect CMake configuration tests Summary: This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20889 llvm-svn: 271458
2016-06-02 09:02:10 +08:00
# Configure compiler.
include(config-ix)
[CMake] Don't use -rtlib=compiler-rt with -nodefaultlibs. Summary: This switch only has an effect at link time. It changes the default compiler support library to `compiler-rt`. With `-nodefaultlibs`, this library won't get linked anyway; Clang actually warns about that. Reviewers: mstorsjo, rnk Subscribers: dberris, mgorny, christof, cfe-commits Differential Revision: https://reviews.llvm.org/D51645 llvm-svn: 341404
2018-09-05 04:57:50 +08:00
if (LIBUNWIND_USE_COMPILER_RT AND NOT LIBUNWIND_HAS_NODEFAULTLIBS_FLAG)
Reland "[CMake][libunwind] Use -nodefaultlibs for CMake checks" This is a reland of commit r299796. Turned out that we need gcc_s or compiler-rt on ARM when checking the support for -funwind-tables which creates a dependency on __aeabi_unwind_cpp_pr0 symbol that's provided by the compiler runtime. Differential Revision: https://reviews.llvm.org/D31858 llvm-svn: 300020
2017-04-12 10:28:07 +08:00
list(APPEND LIBUNWIND_LINK_FLAGS "-rtlib=compiler-rt")
endif()
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags_if_supported(-Werror=return-type)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libunwind] Support stack unwind in CET environment Control-flow Enforcement Technology (CET), published by Intel, introduces shadow stack feature aiming to ensure a return from a function is directed to where the function was called. In a CET enabled system, each function call will push return address into normal stack and shadow stack, when the function returns, the address stored in shadow stack will be popped and compared with the return address, program will fail if the 2 addresses don't match. In exception handling, the control flow may skip some stack frames and we must adjust shadow stack to avoid violating CET restriction. In order to achieve this, we count the number of stack frames skipped and adjust shadow stack by this number before jumping to landing pad. Reviewed By: hjl.tools, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D105968 Signed-off-by: gejin <ge.jin@intel.com>
2021-08-26 16:20:38 +08:00
if (LIBUNWIND_ENABLE_CET)
add_compile_flags_if_supported(-fcf-protection=full)
add_compile_flags_if_supported(-mshstk)
if (NOT LIBUNWIND_SUPPORTS_FCF_PROTECTION_EQ_FULL_FLAG)
message(SEND_ERROR "Compiler doesn't support CET -fcf-protection option!")
endif()
if (NOT LIBUNWIND_SUPPORTS_MSHSTK_FLAG)
message(SEND_ERROR "Compiler doesn't support CET -mshstk option!")
endif()
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
# Get warning flags
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags_if_supported(-W)
add_compile_flags_if_supported(-Wall)
add_compile_flags_if_supported(-Wchar-subscripts)
add_compile_flags_if_supported(-Wconversion)
add_compile_flags_if_supported(-Wmismatched-tags)
add_compile_flags_if_supported(-Wmissing-braces)
add_compile_flags_if_supported(-Wnewline-eof)
add_compile_flags_if_supported(-Wno-unused-function)
add_compile_flags_if_supported(-Wshadow)
add_compile_flags_if_supported(-Wshorten-64-to-32)
add_compile_flags_if_supported(-Wsign-compare)
add_compile_flags_if_supported(-Wsign-conversion)
add_compile_flags_if_supported(-Wstrict-aliasing=2)
add_compile_flags_if_supported(-Wstrict-overflow=4)
add_compile_flags_if_supported(-Wunused-parameter)
add_compile_flags_if_supported(-Wunused-variable)
add_compile_flags_if_supported(-Wwrite-strings)
add_compile_flags_if_supported(-Wundef)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
[libunwind] Add -Wno-suggest-override to CMakeLists.txt. Set -Wno-suggest-override where such warning is provided by the compiler when building libunwind, alongside libcxx and libcxxabi, using recent Clang. This extends behavior introduced in 77e0e9e17daf0865620abcd41f692ab0642367c4 to libunwind, avoiding a large amount of warnings during builds. See D84126 for the original patch.
2020-08-01 01:44:02 +08:00
add_compile_flags_if_supported(-Wno-suggest-override)
[libunwind] Add -Wno-dll-attribute-on-redeclaration when building for windows It's not worth trying to fix these warnings within libunwind, instead silence them. Differential Revision: https://reviews.llvm.org/D90075
2020-10-24 03:51:21 +08:00
if (WIN32)
# The headers lack matching dllexport attributes (_LIBUNWIND_EXPORT);
# silence the warning instead of cluttering the headers (which aren't
# necessarily the ones that the callers will use anyway) with the
# attributes.
add_compile_flags_if_supported(-Wno-dll-attribute-on-redeclaration)
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
if (LIBUNWIND_ENABLE_WERROR)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags_if_supported(-Werror)
add_compile_flags_if_supported(-WX)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
else()
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags_if_supported(-Wno-error)
add_compile_flags_if_supported(-WX-)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
endif()
if (LIBUNWIND_ENABLE_PEDANTIC)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags_if_supported(-pedantic)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
endif()
# Get feature flags.
# Exceptions
# Catches C++ exceptions only and tells the compiler to assume that extern C
# functions never throw a C++ exception.
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_cxx_compile_flags_if_supported(-fstrict-aliasing)
add_cxx_compile_flags_if_supported(-EHsc)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Reland "Enable `-funwind-tables` flag when building libunwind" Summary: Relands https://reviews.llvm.org/D70815. The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively disabled the linking step in CMake checks. This broke some builds (see 938c70b86c7d2165f8c28d5700e9c1ac1263307e). Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY only when checking for presence of the `-funwind-tables` flag, and then set it back to the original value so it doesn't affect other checks. Reviewers: mstorsjo, jfb Subscribers: mgorny, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71117
2019-12-06 22:26:35 +08:00
# Don't run the linker in this CMake check.
#
# The reason why this was added is that when building libunwind for
# ARM Linux, we need to pass the -funwind-tables flag in order for it to
# work properly with ARM EHABI.
#
# However, when performing CMake checks, adding this flag causes the check
# to produce a false negative, because the compiler generates calls
# to __aeabi_unwind_cpp_pr0, which is defined in libunwind itself,
# which isn't built yet, so the linker complains about undefined symbols.
#
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
[libunwind] Fix issues introduced in r374606 There are few differences in compile flags introduced in r374606 which are causing libcxx-libcxxabi-libunwind-armv8-linux to fail. This change should address all of those, I've compared the generated build file from before r374606 and with this change and the set of flags is the same modulo order. llvm-svn: 374624
2019-10-12 09:50:57 +08:00
add_compile_flags_if_supported(-funwind-tables)
Reland "Enable `-funwind-tables` flag when building libunwind" Summary: Relands https://reviews.llvm.org/D70815. The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively disabled the linking step in CMake checks. This broke some builds (see 938c70b86c7d2165f8c28d5700e9c1ac1263307e). Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY only when checking for presence of the `-funwind-tables` flag, and then set it back to the original value so it doesn't affect other checks. Reviewers: mstorsjo, jfb Subscribers: mgorny, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71117
2019-12-06 22:26:35 +08:00
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${_previous_CMAKE_TRY_COMPILE_TARGET_TYPE})
if (LIBUNWIND_USES_ARM_EHABI AND NOT LIBUNWIND_SUPPORTS_FUNWIND_TABLES_FLAG)
message(SEND_ERROR "The -funwind-tables flag must be supported "
"because this target uses ARM Exception Handling ABI")
endif()
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_cxx_compile_flags_if_supported(-fno-exceptions)
add_cxx_compile_flags_if_supported(-fno-rtti)
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Drop the dependency on <algorithm>, add placement new inline We haven't eliminated C++ library dependency altogether in D57251, UnwindCursor.hpp had an unused dependency on <algorithm> which was pulling in other C++ headers. Removing that dependency also revealed (correctly) that we need our own global placement new declaration. Now libunwind should be independent of the C++ library. Differential Revision: https://reviews.llvm.org/D57262 llvm-svn: 352553
2019-01-30 06:26:18 +08:00
# Ensure that we don't depend on C++ standard library.
[libunwind] Fix issues introduced in r374606 There are few differences in compile flags introduced in r374606 which are causing libcxx-libcxxabi-libunwind-armv8-linux to fail. This change should address all of those, I've compared the generated build file from before r374606 and with this change and the set of flags is the same modulo order. llvm-svn: 374624
2019-10-12 09:50:57 +08:00
if (LIBUNWIND_HAS_NOSTDINCXX_FLAG)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
list(APPEND LIBUNWIND_COMPILE_FLAGS -nostdinc++)
# Remove -stdlib flags to prevent them from causing an unused flag warning.
Fix all the CMake code that can only handle -stdlib= but not --stdlib= There are several places in LLVM's CMake setup that try to remove the `stdlib=...` flag from the CMake flags. All this code however only considered the `-stdlib=` variant of the flag but not the alternative spelling with a double dash. This causes that when one adds `--stdlib=...` to the user-provided CMake flags that this gets transformed into just `-` which ends up causing the build system to think it should read the source from stdin (which then lead to very confusing build errors). This just adds the alternative spelling before the`-stdlib=` variant in all these places Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D87133
2020-10-13 22:05:00 +08:00
string(REPLACE "--stdlib=libc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REPLACE "--stdlib=libstdc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
string(REPLACE "-stdlib=libc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REPLACE "-stdlib=libstdc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
endif()
Drop the dependency on <algorithm>, add placement new inline We haven't eliminated C++ library dependency altogether in D57251, UnwindCursor.hpp had an unused dependency on <algorithm> which was pulling in other C++ headers. Removing that dependency also revealed (correctly) that we need our own global placement new declaration. Now libunwind should be independent of the C++ library. Differential Revision: https://reviews.llvm.org/D57262 llvm-svn: 352553
2019-01-30 06:26:18 +08:00
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
# Assert
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
if (LIBUNWIND_ENABLE_ASSERTIONS)
# MSVC doesn't like _DEBUG on release builds. See PR 4379.
if (NOT MSVC)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-D_DEBUG)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
# On Release builds cmake automatically defines NDEBUG, so we
# explicitly undefine it:
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-UNDEBUG)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
else()
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-DNDEBUG)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Introduce a native-only unwinder build. Currently libunwind is built to support cross-unwinding [1] by default, which requires the buffers unw_context_t and unw_cursor_t to be large enough to hold the vritual register set (VRS) of any supported architecture. This is not desirable for some platforms where the stack usage of the unwinder needs to be kept to a minimum (e.g. bare-metal targets). The current patch introduces a native-only (-DLIBUNWIND_ENABLE_CROSS_UNWINDING=OFF) unwinder variant that adopts strict sizes for the buffers unw_context_t and unw_cursor_t depending on the target architecture. [1] http://www.nongnu.org/libunwind/man/libunwind(3).html#section_4 Change-Id: I380fff9a56c16a0fc520e3b1d8454a34b4a48373 llvm-svn: 270692
2016-05-25 20:36:34 +08:00
# Cross-unwinding
if (NOT LIBUNWIND_ENABLE_CROSS_UNWINDING)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-D_LIBUNWIND_IS_NATIVE_ONLY)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
Introduce a native-only unwinder build. Currently libunwind is built to support cross-unwinding [1] by default, which requires the buffers unw_context_t and unw_cursor_t to be large enough to hold the vritual register set (VRS) of any supported architecture. This is not desirable for some platforms where the stack usage of the unwinder needs to be kept to a minimum (e.g. bare-metal targets). The current patch introduces a native-only (-DLIBUNWIND_ENABLE_CROSS_UNWINDING=OFF) unwinder variant that adopts strict sizes for the buffers unw_context_t and unw_cursor_t depending on the target architecture. [1] http://www.nongnu.org/libunwind/man/libunwind(3).html#section_4 Change-Id: I380fff9a56c16a0fc520e3b1d8454a34b4a48373 llvm-svn: 270692
2016-05-25 20:36:34 +08:00
[libunwind] Add support for a single-threaded libunwind build The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder have a couple of pthread dependencies. This patch makes it possible to build the whole of libunwind for a single-threaded environment. Reviewers: compnerd Differential revision: https://reviews.llvm.org/D24984 llvm-svn: 282575
2016-09-28 18:57:15 +08:00
# Threading-support
if (NOT LIBUNWIND_ENABLE_THREADS)
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-D_LIBUNWIND_HAS_NO_THREADS)
[libunwind] Add support for a single-threaded libunwind build The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder have a couple of pthread dependencies. This patch makes it possible to build the whole of libunwind for a single-threaded environment. Reviewers: compnerd Differential revision: https://reviews.llvm.org/D24984 llvm-svn: 282575
2016-09-28 18:57:15 +08:00
endif()
[libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional These registers are only available on a limited set of ARM targets (those based on XScale). Other targets should not have to pay the cost of these. This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size. Differential revision: http://reviews.llvm.org/D21991 Reviewers: bcraig, compnerd Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7 llvm-svn: 274744
2016-07-07 18:55:39 +08:00
# ARM WMMX register support
if (LIBUNWIND_ENABLE_ARM_WMMX)
# __ARM_WMMX is a compiler pre-define (as per the ACLE 2.0). Clang does not
# define this macro for any supported target at present. Therefore, here we
# provide the option to explicitly enable support for WMMX registers in the
# unwinder.
[libunwind] Refactor CMake flag checks to match libc++ and libc++abi libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
2019-10-12 06:22:29 +08:00
add_compile_flags(-D__ARM_WMMX)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
[libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional These registers are only available on a limited set of ARM targets (those based on XScale). Other targets should not have to pay the cost of these. This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size. Differential revision: http://reviews.llvm.org/D21991 Reviewers: bcraig, compnerd Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7 llvm-svn: 274744
2016-07-07 18:55:39 +08:00
[libunwind] Provide a way to set '_LIBUNWIND_IS_BAREMETAL' through cmake. Libunwind uses _LIBUNWIND_IS_BAREMETAL in a lot of places but there is no cmake variable to set it. This patch adds such a variable. It is quite like what LIBCXXABI_BAREMETAL does in libcxxabi. Reviewed By: compnerd, #libunwind Differential Revision: https://reviews.llvm.org/D84759
2020-07-29 18:39:41 +08:00
if(LIBUNWIND_IS_BAREMETAL)
add_compile_definitions(_LIBUNWIND_IS_BAREMETAL)
endif()
Default to disabling the libunwind frameheader cache. Although it works fine with glibc, as currently implemented the frameheader cache is incompatible with certain platforms with slightly different locking semantics inside dl_iterate_phdr. Therefore only enable it when it is turned on explicitly with a configure-time option. Differential Revision: https://reviews.llvm.org/D86163
2020-08-19 03:05:07 +08:00
if(LIBUNWIND_USE_FRAME_HEADER_CACHE)
add_compile_definitions(_LIBUNWIND_USE_FRAME_HEADER_CACHE)
endif()
[libunwind] LIBUNWIND_REMEMBER_HEAP_ALLOC to cmake. Missed it originally in https://reviews.llvm.org/D85005. Reviewed By: gargaroff Differential Revision: https://reviews.llvm.org/D91182
2020-11-11 17:58:41 +08:00
if(LIBUNWIND_REMEMBER_HEAP_ALLOC)
add_compile_definitions(_LIBUNWIND_REMEMBER_HEAP_ALLOC)
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
# This is the _ONLY_ place where add_definitions is called.
if (MSVC)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
CMakeLists.txt cleanups: synchronize version and CMake minimum required version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23094 llvm-svn: 278029
2016-08-09 01:56:28 +08:00
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
Support building libunwind as a DLL Differential Revision: https://reviews.llvm.org/D40483 llvm-svn: 319300
2017-11-29 16:21:12 +08:00
# Disable DLL annotations on Windows for static builds.
if (WIN32 AND LIBUNWIND_ENABLE_STATIC AND NOT LIBUNWIND_ENABLE_SHARED)
[libunwind] unw_* alias fixes for ELF and Mach-O Rename the CMake option, LIBUNWIND_HERMETIC_STATIC_LIBRARY, to LIBUNWIND_HIDE_SYMBOLS. Rename the C macro define, _LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS, to _LIBUNWIND_HIDE_SYMBOLS, because now the macro adds a .hidden directive rather than merely suppress visibility annotations. For ELF, when LIBUNWIND_HIDE_SYMBOLS is enabled, mark unw_getcontext as hidden. This symbol is the only one defined using src/assembly.h's WEAK_ALIAS macro. Other unw_* weak aliases are defined in C++ and are already hidden. Mach-O doesn't support weak aliases, so remove .weak_reference and weak_import. When LIBUNWIND_HIDE_SYMBOLS is enabled, output .private_extern for the unw_* aliases. In assembly.h, add missing SYMBOL_NAME macro invocations, which are used to prefix symbol names with '_' on some targets. Fixes PR46709. Reviewed By: #libunwind, phosek, compnerd, steven_wu Differential Revision: https://reviews.llvm.org/D93003
2021-02-23 08:35:38 +08:00
add_definitions(-D_LIBUNWIND_HIDE_SYMBOLS)
Support building libunwind as a DLL Differential Revision: https://reviews.llvm.org/D40483 llvm-svn: 319300
2017-11-29 16:21:12 +08:00
endif()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
if (LIBUNWIND_HAS_COMMENT_LIB_PRAGMA)
[libunwind] Emit dependent libraries only when detected by CMake 996e62eef75 added Linux-specific dependent libraries to libunwind sources. As a result, building libunwind with modern LLD on *BSD started failing due to trying to link libdl. Instead, add those libraries only if they were detected by CMake. While technically we could create a long list of systems that need -ldl and -lpthread, maintaining a duplicate list makes little sense when CMake needs to detect it for non-LLD systems anyway. Remove existing system exceptions since they should be covered by the CMake check anyway. Remove -D_LIBUNWIND_HAS_COMMENT_LIB_PRAGMA since it is no longer explicitly needed, if we make the library-specific defines dependent on presence of this pragma support. Differential Revision: https://reviews.llvm.org/D70868
2019-11-30 22:13:56 +08:00
if (LIBUNWIND_HAS_DL_LIB)
add_definitions(-D_LIBUNWIND_LINK_DL_LIB)
endif()
if (LIBUNWIND_HAS_PTHREAD_LIB)
add_definitions(-D_LIBUNWIND_LINK_PTHREAD_LIB)
endif()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
endif()
libunwind: add new build logic This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
2015-04-25 09:46:35 +08:00
#===============================================================================
# Setup Source Code
#===============================================================================
include_directories(include)
add_subdirectory(src)
[libunwind] Add sphinx docs https://reviews.llvm.org/D31375 llvm-svn: 298922
2017-03-28 23:21:43 +08:00
if (LIBUNWIND_INCLUDE_DOCS)
add_subdirectory(docs)
endif()
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
[LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D107717
2021-09-17 00:27:53 +08:00
if (LIBUNWIND_INCLUDE_TESTS AND EXISTS ${LLVM_CMAKE_DIR})
[CMake] Allow building standalone without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50135 llvm-svn: 338819
2018-08-03 13:51:31 +08:00
add_subdirectory(test)
endif()