Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2024-11-23 13:50:11 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
600a1b3d97
llvm-capstone/libunwind/CMakeLists.txt

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

328 lines
13 KiB
CMake
Raw Normal View History

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 01:46:35 +00:00
#===============================================================================
Revert test commit. llvm-svn: 244297
2015-08-06 23:31:37 +00: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 01:46:35 +00:00
#===============================================================================
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 16:12:32 +00:00
cmake_minimum_required(VERSION 3.20.0)
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 01:46:35 +00:00
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
set(LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
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 02:28:07 +00:00
# Add path for custom modules
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
list(INSERT CMAKE_MODULE_PATH 0
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 02:28:07 +00:00
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
[runtimes] Move common functions from Handle{Libcxx,Libcxxabi,Libunwind}Flags.cmake to runtimes/cmake/Modules/HandleFlags.cmake Reviewed By: phosek, #libunwind, #libc, #libc_abi Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D144395
2023-02-20 15:26:19 +00:00
"${CMAKE_CURRENT_SOURCE_DIR}/../runtimes/cmake/Modules"
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
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 02:28:07 +00: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 09:01:05 +00: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] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
include(GNUInstallDirs)
MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521) Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com> (cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
2024-02-08 01:15:53 +00:00
include(CheckSymbolExists)
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00: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 01:46:35 +00:00
#===============================================================================
# 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-24 23:42:51 +00: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 02:28:07 +00: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 01:46:35 +00:00
# Define options.
[runtimes] Remove support for GCC-style 32 bit multilib builds This patch removes the ability to build the runtimes in the 32 bit multilib configuration, i.e. using -m32. Instead of doing this, one should cross-compile the runtimes for the appropriate target triple, like we do for all other triples. As it stands, -m32 has several issues, which all seem to be related to the fact that it's not well supported by the operating systems that libc++ support. The simplest path towards fixing this is to remove support for the configuration, which is also the best course of action if there is little interest for keeping that configuration. If there is a desire to keep this configuration around, we'll need to do some work to figure out the underlying issues and fix them. Differential Revision: https://reviews.llvm.org/D114473
2021-11-23 21:34:09 +00:00
option(LIBUNWIND_BUILD_32_BITS "Build 32 bit multilib libunwind. This option is not supported anymore when building the runtimes. Please specify a full triple instead." ${LLVM_BUILD_32_BITS})
if (LIBUNWIND_BUILD_32_BITS)
[runtimes] Move WARNING to FATAL_ERROR for folks using FOO_BUILD_32_BITS
2021-12-01 17:57:30 +00:00
message(FATAL_ERROR "LIBUNWIND_BUILD_32_BITS is not supported anymore when building the runtimes, please specify a full triple instead.")
[runtimes] Remove support for GCC-style 32 bit multilib builds This patch removes the ability to build the runtimes in the 32 bit multilib configuration, i.e. using -m32. Instead of doing this, one should cross-compile the runtimes for the appropriate target triple, like we do for all other triples. As it stands, -m32 has several issues, which all seem to be related to the fact that it's not well supported by the operating systems that libc++ support. The simplest path towards fixing this is to remove support for the configuration, which is also the best course of action if there is little interest for keeping that configuration. If there is a desire to keep this configuration around, we'll need to do some work to figure out the underlying issues and fix them. Differential Revision: https://reviews.llvm.org/D114473
2021-11-23 21:34:09 +00:00
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 08:20:38 +00: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 01:46:35 +00: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-08 22:55:48 +00: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 08:29:27 +00: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 10:55:39 +00: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 10:57:15 +00: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-13 18:45:03 +00: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 02:28:07 +00: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 15:21:43 +00: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 10:49:47 +00: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 10:39:41 +00: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-18 19:05:07 +00: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 09:58:41 +00:00
option(LIBUNWIND_REMEMBER_HEAP_ALLOC "Use heap instead of the stack for .cfi_remember_state." OFF)
[libunwind] Install the headers by default Just like we install libc++ and libc++abi headers by default when we install the library, it makes sense to install the libunwind headers by default when we build libunwind. In the current state of things, there is an increased risk that folks are using older (previously installed) libunwind headers along with a recent libunwind dylib, which is not ideal. Differential Revision: https://reviews.llvm.org/D135663
2022-10-11 13:19:55 +00:00
option(LIBUNWIND_INSTALL_HEADERS "Install the libunwind headers." ON)
Make _LIBUNWIND_SUPPORT_FRAME_APIS a build-time option Previously this was based on target architecture, but that makes very little sense--frame API availability is generally for libgcc compatibility and that is dependent on runtime needs rather than target architecture. Default this to on, so as not to remove the apis from environments that already have them. The functions this macro protects are stubs for libgcc-compatibility. Today, libunwind as a drop-in replacement for libgcc_eh links on x86, x86_64, and powerpc, but not aarch64, which doesn't really make sense. As there is nothing architecture specific about these, they should be provided everywhere or nowhere. The target-specific protection goes all the way back to the original code contribution in 312fcd0e1cf14482b2ae8eee8234541dcc3bc2c4 from 2013, so the original reason is lost to history, and probably not relevant today. Differential Revision: https://reviews.llvm.org/D158011
2023-08-15 18:36:30 +00:00
option(LIBUNWIND_ENABLE_FRAME_APIS "Include libgcc-compatible frame apis." 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 01:46:35 +00:00
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-19 02:44:46 +00: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-17 23:29:46 +00: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-24 23:27:51 +00: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)
[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-12 18:10:02 +00:00
[libunwind] [test] Add a mingw specific test config file This matches how it is done for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D147633
2023-03-29 21:36:51 +00:00
if(MINGW)
set(LIBUNWIND_DEFAULT_TEST_CONFIG "llvm-libunwind-mingw.cfg.in")
elseif (LIBUNWIND_ENABLE_SHARED)
[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-12 18:10:02 +00:00
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-29 19:26:05 +00: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-12 16:46:21 +00: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-29 19:26:05 +00: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-12 16:46:21 +00: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-29 19:26:05 +00:00
endif()
[runtimes] Print the testing configuration in use in libunwind and libc++abi We do it for libc++, and it's rather useful for debugging e.g. CI.
2022-05-11 14:16:29 +00:00
message(STATUS "Using libunwind testing configuration: ${LIBUNWIND_TEST_CONFIG}")
[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 09:01:05 +00: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 01:46:35 +00: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-08 22:55:48 +00: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 08:20:38 +00:00
if (LIBUNWIND_ENABLE_CET AND MSVC)
message(FATAL_ERROR "libunwind CET support is not available for MSVC!")
endif()
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows (In the case of libunwind, the cmake option is called LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as LIBCXX_HERMETIC_STATIC_LIBRARY and LIBCXXABI_HERMETIC_STATIC_LIBRARY.) Previously, the same issue was dealt with by setting a project wide define (_LIBUNWIND_HIDE_SYMBOLS, _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static library. If building both static and shared at the same time, this wasn't set, and the static library would contain dllexport directives. The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake options only apply the defines to the static library in the build, even if building both static and shared at the same time. (This could only be done use after the object libraries were enabled, as a shared libcxx needs libcxxabi object files built with dllexports included.) This allows removing inelegant code for deciding how to build the libcxxabi static library and a TODO comment that suggested that users should need to start setting an option, which they shouldn't need to. Finally, this gets rid of two XFAILs in tests. Differential Revision: https://reviews.llvm.org/D125715
2022-04-09 20:40:07 +00:00
if (WIN32)
set(LIBUNWIND_DEFAULT_HIDE_SYMBOLS TRUE)
else()
set(LIBUNWIND_DEFAULT_HIDE_SYMBOLS FALSE)
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 00:35:38 +00:00
option(LIBUNWIND_HIDE_SYMBOLS
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows (In the case of libunwind, the cmake option is called LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as LIBCXX_HERMETIC_STATIC_LIBRARY and LIBCXXABI_HERMETIC_STATIC_LIBRARY.) Previously, the same issue was dealt with by setting a project wide define (_LIBUNWIND_HIDE_SYMBOLS, _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static library. If building both static and shared at the same time, this wasn't set, and the static library would contain dllexport directives. The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake options only apply the defines to the static library in the build, even if building both static and shared at the same time. (This could only be done use after the object libraries were enabled, as a shared libcxx needs libcxxabi object files built with dllexports included.) This allows removing inelegant code for deciding how to build the libcxxabi static library and a TODO comment that suggested that users should need to start setting an option, which they shouldn't need to. Finally, this gets rid of two XFAILs in tests. Differential Revision: https://reviews.llvm.org/D125715
2022-04-09 20:40:07 +00:00
"Do not export any symbols from the static library." ${LIBUNWIND_DEFAULT_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-29 23:01:08 +00:00
MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521) Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com> (cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
2024-02-08 01:15:53 +00:00
# If toolchain is FPXX, we switch to FP64 to save the full FPRs. See:
# https://web.archive.org/web/20180828210612/https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
check_symbol_exists(__mips_hard_float "" __MIPSHF)
check_symbol_exists(_ABIO32 "" __MIPS_O32)
if (__MIPSHF AND __MIPS_O32)
file(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/mips_is_fpxx.c
"#if __mips_fpr != 0\n"
"# error\n"
"#endif\n")
try_compile(MIPS_FPABI_FPXX ${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/mips_is_fpxx.c
CMAKE_FLAGS -DCMAKE_C_LINK_EXECUTABLE='echo')
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 01:46:35 +00:00
#===============================================================================
# Configure System
#===============================================================================
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
${CMAKE_MODULE_PATH})
[libunwind] Convert a few options from CACHE PATH to CACHE STRING (#77534) This applies the same change as in 760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi and libcxx) to libunwind as well. These options can reasonably be set either as an absolute or relative path, but if set as type PATH, they are rewritten from relative into absolute relative to the build directory, while the relative form is intended to be relative to the install prefix.
2024-01-10 09:25:17 +00:00
set(LIBUNWIND_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}" CACHE STRING
[libc++][libc++abi][libunwind] Dedup install path var definitions In D116873 I did this for libunwind prior to defining a new install path variable. But I think the change is good on its own, and libc++{,abi} could also use it. libc++ needed the base header var defined above the conditional part to use it for the prefi+ed headers in the non-target-specific case. For consistency, I therefore put the unconditional ones above for all 3 libs, which is why I touched the libunwind code (seeing that it had the core change already) Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116988
2022-01-11 03:03:21 +00:00
"Path where built libunwind headers should be installed.")
[libunwind] Convert a few options from CACHE PATH to CACHE STRING (#77534) This applies the same change as in 760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi and libcxx) to libunwind as well. These options can reasonably be set either as an absolute or relative path, but if set as type PATH, they are rewritten from relative into absolute relative to the build directory, while the relative form is intended to be relative to the install prefix.
2024-01-10 09:25:17 +00:00
set(LIBUNWIND_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE STRING
[libc++][libc++abi][libunwind] Dedup install path var definitions In D116873 I did this for libunwind prior to defining a new install path variable. But I think the change is good on its own, and libc++{,abi} could also use it. libc++ needed the base header var defined above the conditional part to use it for the prefi+ed headers in the non-target-specific case. For consistency, I therefore put the unconditional ones above for all 3 libs, which is why I touched the libunwind code (seeing that it had the core change already) Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116988
2022-01-11 03:03:21 +00:00
"Path where built libunwind runtime libraries should be installed.")
[runtimes] Add the ability to customize the output name of libc++, libc++abi and libunwind We already had the ability to do that for libc++.dylib, so this only adds consistency for all the runtime libraries. This should allow working around difficulties on AIX as described in https://llvm.org/D134221. Differential Revision: https://reviews.llvm.org/D135669
2022-10-11 14:05:56 +00:00
set(LIBUNWIND_SHARED_OUTPUT_NAME "unwind" CACHE STRING "Output name for the shared libunwind runtime library.")
set(LIBUNWIND_STATIC_OUTPUT_NAME "unwind" CACHE STRING "Output name for the static libunwind runtime library.")
Revert "Revert "Support for multiarch runtimes layout"" This reverts commit r336005 that was accidentally committed. llvm-svn: 336012
2018-06-29 20:27:40 +00:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
Revert "[CMake] Use LLVM_TARGET_TRIPLE in runtimes" This reverts commit bec8a372fc0db95852748691c0f4933044026b25. This causes many of these errors to appear when rebuilding runtimes part of fuchsia's toolchain: ld.lld: error: /usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o) is incompatible with elf64-x86-64 This can be reproduced by making a complete toolchain, saving any source file with no changes, then rerunning ninja distribution.
2022-12-05 22:20:51 +00:00
set(LIBUNWIND_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
[libunwind] Convert a few options from CACHE PATH to CACHE STRING (#77534) This applies the same change as in 760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi and libcxx) to libunwind as well. These options can reasonably be set either as an absolute or relative path, but if set as type PATH, they are rewritten from relative into absolute relative to the build directory, while the relative form is intended to be relative to the install prefix.
2024-01-10 09:25:17 +00:00
set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE STRING
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-28 22:36:47 +00:00
"Path where built libunwind 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-22 21:08:33 +00:00
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBUNWIND_LIBRARY_DIR /${LIBUNWIND_LIBDIR_SUBDIR})
string(APPEND LIBUNWIND_INSTALL_LIBRARY_DIR /${LIBUNWIND_LIBDIR_SUBDIR})
endif()
[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-18 21:30:18 +00:00
else()
[libunwind][cmake] Create `LIBUNWIND_INSTALL_INCLUDE_DIR` CACHE PATH This is created on analogy with the other CACHE PATHs in this package, and other `*_INSTALL_INCLUDE_DIR` in other packages. The branching is adjusted to deduplicate some existing code, and likewise avoid having to define this new variable more than once. This will be used for D99484. Reviewed By: #libunwind, compnerd Differential Revision: https://reviews.llvm.org/D116873
2022-01-09 00:08:15 +00:00
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LIBUNWIND_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
else()
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-19 02:44:46 +00:00
set(LIBUNWIND_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBUNWIND_LIBDIR_SUFFIX})
[libunwind][cmake] Create `LIBUNWIND_INSTALL_INCLUDE_DIR` CACHE PATH This is created on analogy with the other CACHE PATHs in this package, and other `*_INSTALL_INCLUDE_DIR` in other packages. The branching is adjusted to deduplicate some existing code, and likewise avoid having to define this new variable more than once. This will be used for D99484. Reviewed By: #libunwind, compnerd Differential Revision: https://reviews.llvm.org/D116873
2022-01-09 00:08:15 +00:00
endif()
[libunwind] Convert a few options from CACHE PATH to CACHE STRING (#77534) This applies the same change as in 760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi and libcxx) to libunwind as well. These options can reasonably be set either as an absolute or relative path, but if set as type PATH, they are rewritten from relative into absolute relative to the build directory, while the relative form is intended to be relative to the install prefix.
2024-01-10 09:25:17 +00:00
set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LIBUNWIND_LIBDIR_SUFFIX} CACHE STRING
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-28 22:36:47 +00:00
"Path where built libunwind 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-18 21:30:18 +00: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 01:46:35 +00: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 01:02:10 +00:00
set(LIBUNWIND_C_FLAGS "")
set(LIBUNWIND_CXX_FLAGS "")
set(LIBUNWIND_COMPILE_FLAGS "")
set(LIBUNWIND_LINK_FLAGS "")
[libunwind] Add cached compile and link flags to libunwind Add flags allowing to use compile flags and libraries provided in cache with libunwind. Similar flags are already present in libc++ and libc++abi CMakeLists files. Differential Revision: https://reviews.llvm.org/D150252
2023-06-29 07:41:08 +00:00
set(LIBUNWIND_ADDITIONAL_COMPILE_FLAGS "" CACHE STRING
"Additional Compile only flags which can be provided in cache")
set(LIBUNWIND_ADDITIONAL_LIBRARIES "" CACHE STRING
"Additional libraries libunwind is linked to which can be provided in cache")
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 01:46:35 +00: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-11 22:22:29 +00: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 01:02:10 +00: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-04 20:57:50 +00: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 02:28:07 +00: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-11 22:22:29 +00: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 01:46:35 +00: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 08:20:38 +00:00
if (LIBUNWIND_ENABLE_CET)
add_compile_flags_if_supported(-fcf-protection=full)
add_compile_flags_if_supported(-mshstk)
[CMake] Fix LIBUNWIND_ENABLE_CET build after D110005 D110005 renamed LIBUNWIND_SUPPORTS_* to CXX_SUPPORTS_*. Reviewed By: MaskRay, #libunwind, mstorsjo Differential Revision: https://reviews.llvm.org/D136131
2022-10-18 22:00:09 +00:00
if (NOT CXX_SUPPORTS_FCF_PROTECTION_EQ_FULL_FLAG)
[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 08:20:38 +00:00
message(SEND_ERROR "Compiler doesn't support CET -fcf-protection option!")
endif()
[CMake] Fix LIBUNWIND_ENABLE_CET build after D110005 D110005 renamed LIBUNWIND_SUPPORTS_* to CXX_SUPPORTS_*. Reviewed By: MaskRay, #libunwind, mstorsjo Differential Revision: https://reviews.llvm.org/D136131
2022-10-18 22:00:09 +00:00
if (NOT CXX_SUPPORTS_MSHSTK_FLAG)
[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 08:20:38 +00:00
message(SEND_ERROR "Compiler doesn't support CET -mshstk option!")
endif()
endif()
[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-23 19:51:21 +00: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()
MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521) Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com> (cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
2024-02-08 01:15:53 +00:00
if (MIPS_FPABI_FPXX)
add_compile_flags(-mfp64)
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 01:46:35 +00:00
# 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-11 22:22:29 +00: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 01:46:35 +00: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 14:26:35 +00: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 01:50:57 +00: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 14:26:35 +00:00
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${_previous_CMAKE_TRY_COMPILE_TARGET_TYPE})
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 09:47:09 +00:00
if (LIBUNWIND_USES_ARM_EHABI AND NOT CXX_SUPPORTS_FUNWIND_TABLES_FLAG)
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 14:26:35 +00:00
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-11 22:22:29 +00: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 01:46:35 +00: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-29 22:26:18 +00:00
# Ensure that we don't depend on C++ standard library.
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 09:47:09 +00:00
if (CXX_SUPPORTS_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-11 22:22:29 +00: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 14:05:00 +00: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-11 22:22:29 +00: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-29 22:26:18 +00: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 01:46:35 +00: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-11 22:22:29 +00: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-08 17:56:28 +00: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 01:46:35 +00:00
# On Release builds cmake automatically defines NDEBUG, so we
# explicitly undefine it:
[libunwind] [CMake] Handle the RelWithDebInfo configuration similarly to Release This makes sure to include libunwind log messages in the build if LIBUNWIND_ENABLE_ASSERTIONS is set (which it is by default), when building in RelWithDebInfo configurations. Differential Revision: https://reviews.llvm.org/D124912
2022-05-04 09:52:20 +00:00
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
[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-11 22:22:29 +00: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-08 17:56:28 +00: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 01:46:35 +00:00
else()
[libunwind] [CMake] Handle the RelWithDebInfo configuration similarly to Release This makes sure to include libunwind log messages in the build if LIBUNWIND_ENABLE_ASSERTIONS is set (which it is by default), when building in RelWithDebInfo configurations. Differential Revision: https://reviews.llvm.org/D124912
2022-05-04 09:52:20 +00:00
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
[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-11 22:22:29 +00: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-08 17:56:28 +00: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 01:46:35 +00: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 12:36:34 +00: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-11 22:22:29 +00: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-08 17:56:28 +00: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 12:36:34 +00:00
Make _LIBUNWIND_SUPPORT_FRAME_APIS a build-time option Previously this was based on target architecture, but that makes very little sense--frame API availability is generally for libgcc compatibility and that is dependent on runtime needs rather than target architecture. Default this to on, so as not to remove the apis from environments that already have them. The functions this macro protects are stubs for libgcc-compatibility. Today, libunwind as a drop-in replacement for libgcc_eh links on x86, x86_64, and powerpc, but not aarch64, which doesn't really make sense. As there is nothing architecture specific about these, they should be provided everywhere or nowhere. The target-specific protection goes all the way back to the original code contribution in 312fcd0e1cf14482b2ae8eee8234541dcc3bc2c4 from 2013, so the original reason is lost to history, and probably not relevant today. Differential Revision: https://reviews.llvm.org/D158011
2023-08-15 18:36:30 +00:00
# Include stubs for __register_frame_info_bases and related
if (LIBUNWIND_ENABLE_FRAME_APIS)
add_compile_flags(-D_LIBUNWIND_SUPPORT_FRAME_APIS)
endif()
[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 10:57:15 +00: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-11 22:22:29 +00: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 10:57:15 +00: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 10:55:39 +00: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-11 22:22:29 +00: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-08 17:56:28 +00: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 10:55:39 +00: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 10:39:41 +00: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-18 19:05:07 +00: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 09:58:41 +00: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 01:46:35 +00: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-08 17:56:28 +00: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 01:46:35 +00:00
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 09:47:09 +00:00
if (C_SUPPORTS_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 14:13:56 +00: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 04:40:21 +00: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 01:46:35 +00:00
#===============================================================================
# Setup Source Code
#===============================================================================
[libunwind] Provide a way to conveniently install libunwind headers This adds a CMake option (defaults to OFF to not be intrusive) to activate 2 new targets `install-unwind-headers` and `install-unwind-headers-stripped`. So, for example: cmake -S runtimes -B build -G Ninja \ -DLLVM_ENABLE_RUNTIMES='libunwind' \ -DLIBUNWIND_INSTALL_HEADERS=ON And then, `ninja -C build install-unwind` would install headers in addition to good ol' dylibs and archives, i.e., targets `install-unwind*` `DEPENDS` on `install-unwind-headers*`. On the other hand, `ninja -C build install-unwind-headers` gives you headers only. Differential Revision: https://reviews.llvm.org/D115535
2021-12-16 18:32:12 +00:00
add_subdirectory(include)
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 01:46:35 +00:00
add_subdirectory(src)
[libunwind] Add sphinx docs https://reviews.llvm.org/D31375 llvm-svn: 298922
2017-03-28 15:21:43 +00: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 15:20:12 +00: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-16 16:27:53 +00: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 05:51:31 +00:00
add_subdirectory(test)
endif()
Reference in New Issue Copy Permalink