summaryrefslogtreecommitdiffstats
path: root/libunwind/src/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* unwind: restore the LINKER_LANGUAGESaleem Abdulrasool2019-11-061-0/+6
| | | | | | | | | | | Have CMake treat the unwind libraries as C libraries rather than C++. There is no C++ runtime dependency at runtime. This ensures that we do not accidentally end up with a link against the C++ runtime. We need to explicitly reset the implicitly linked libraries for C++ to ensure that we do not have CMake force the link against the C++ runtime. This adjustment should enable the NetBSD bots to be happy with this change.
* unwind: reflow some of the build rules (NFC)Saleem Abdulrasool2019-11-061-32/+16
| | | | | Reflow the CMake properties to take less vertical space. This just makes it easier to read. NFC.
* unwind: disable RTTI during the build of libunwindSaleem Abdulrasool2019-11-061-0/+10
| | | | | | | | | Disable the type information emission for libunwind. libunwind does not use `dynamic_cast`. This results in a smaller binary, and more importantly, avoids the dependency on libc++abi. This ensures that we have complete symbol resolution of symbols on ELF targets without linking to the C++ runtime support library. This change avoids the emission of a reference to `__si_class_type_info`.
* Revert "build: explicitly set the linker language for unwind"Saleem Abdulrasool2019-11-061-2/+0
| | | | | | This reverts commit 6db7a5cd7c800a588e94ce5c1ef24ae4d60ecdd3. This adversely impacted the NetBSD libc++ bot for some reason, reverting while investigating.
* build: explicitly set the linker language for unwindSaleem Abdulrasool2019-11-041-0/+2
| | | | | | The unwinder should not depend on libc++. In fact, we do not end up with a link against libc++ as we do not have a dependency on libc++ at runtime. This ensures that we link with `clang` rather than `clang++`.
* [libunwind] Fix issues introduced in r374606Petr Hosek2019-10-121-0/+4
| | | | | | | | | | 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
* [libunwind] Refactor CMake flag checks to match libc++ and libc++abiPetr Hosek2019-10-111-36/+49
| | | | | | | | | | | | | | | | | 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
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-221-2/+2
| | | | | | | | | | | | | | | | | 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
* Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to forceSterling Augustine2019-05-131-0/+1
| | | | | | | | | | | 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
* [gn] Support for building libunwindPetr Hosek2019-05-021-6/+11
| | | | | | | | | | | | This change introduces support for building libuwind. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D60370 llvm-svn: 359804
* [libunwind] Do not share an object library to create the static/shared librariesPetr Hosek2019-04-031-37/+12
| | | | | | This change is similar to r356150, with the same motivation. llvm-svn: 357606
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-081-2/+2
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-081-2/+2
| | | | | | | | | | | | | | | 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> and include/ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59013 llvm-svn: 355665
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352688
* Revert "[CMake] Use correct visibility for linked libraries in CMake"Petr Hosek2019-01-301-2/+2
| | | | | | This reverts commit r352654: this broke libcxx and sanitizer bots. llvm-svn: 352658
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352654
* [libunwind] Support building hermetic static libraryPetr Hosek2019-01-291-7/+34
| | | | | | | | | | | | | | | 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
* [cmake] Rename append_if to avoid collision with LLVMMichal Gorny2018-12-111-10/+10
| | | | | | | | | | | Rename the 'append_if' macro used in libunwind to 'unwind_append_if'. Otherwise, when used in a combined LLVM+libunwind build, it overrides the *incompatible* 'append_if' function from LLVM and breaks projects following libunwind, e.g. OpenMP. Differential Revision: https://reviews.llvm.org/D55476 llvm-svn: 348852
* [CMake] Link to compiler-rt if LIBUNWIND_USE_COMPILER_RT is ON.Charles Davis2018-10-081-1/+6
| | | | | | | | | | | | | | | | | | Summary: If `-nodefaultlibs` is given, we weren't actually linking to it. This was true irrespective of passing `-rtlib=compiler-rt` (see previous patch). Now we explicitly link it to handle that case. I wonder if we should be linking these libraries only if we're using `-nodefaultlibs`... Reviewers: beanz Subscribers: dberris, mgorny, christof, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D51657 llvm-svn: 343990
* [CMake] Remove variable reference that isn't used.Charles Davis2018-09-041-1/+1
| | | | | | | | | | | | | | | Summary: This variable is never defined, so its value is always empty. Since `libunwind` is needed to build the C++ ABI library in the first place, it should never be linked to the C++ ABI library anyway. Reviewers: mstorsjo, rnk Subscribers: mgorny, christof, cfe-commits Differential Revision: https://reviews.llvm.org/D51644 llvm-svn: 341388
* Add support for SEH unwinding on Windows.Charles Davis2018-08-301-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: I've tested this implementation on x86-64 to ensure that it works. All `libc++abi` tests pass, as do all `libc++` exception-related tests. ARM still remains to be implemented (@compnerd?). Special thanks to KJK::Hyperion for his excellent series of articles on how EH works on x86-64 Windows. (Seriously, check it out. It's awesome.) I'm actually not sure if this should go in as is. I particularly don't like that I duplicated the UnwindCursor class for this special case. Reviewers: mstorsjo, rnk, compnerd, smeenai, javed.absar Subscribers: mgorny, kristof.beyls, christof, chrib, cfe-commits, compnerd, llvm-commits Differential Revision: https://reviews.llvm.org/D50564 llvm-svn: 341125
* [libunwind][mips] Include gcc_s for linkageStefan Maksimovic2018-08-161-0/+1
| | | | | | | | | When compiling with optimizations, mips requires various helper routines(__ashldi3 and the like) contained in libgcc_s. Conditionally include libgcc_s in the set of libraries to be linked to. Differential Revision: https://reviews.llvm.org/D50243 llvm-svn: 339878
* [cmake] Add MINGW_LIBRARIES to the linker flagsMartin Storsjo2018-08-141-0/+3
| | | | | | | | | | | | | | | | | This is essential when building with -nodefaultlibs. In some CMake versions (noticed in 3.5.1), the same libraries are picked up from CMAKE_REQUIRED_LIBRARIES in some exceptional situations (if CXX probing failed, due to libc++ not being built yet, the libraries from CMAKE_REQUIRED_LIBRARIES are used for linking the target library), but not at all in other newer CMake versions (3.10). This is similar to what already is done in libcxxabi in SVN r302760 and libcxx in SVN r312498. Differential Revision: https://reviews.llvm.org/D50663 llvm-svn: 339642
* [CMake] Option to control whether shared/static library is installedPetr Hosek2018-07-241-6/+10
| | | | | | | | | | | | | 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
* [cmake] Remove duplicate command line options from buildAaron Smith2018-04-051-2/+2
| | | | | | | | | | | | | CMAKE_CXX_FLAGS and CMAKE_C_FLAGS are added twice to the command line. This causes the command line options to be doubled which works until it doesn't as not all options can be specified twice. For example, clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1 clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times! llvm-svn: 329340
* [cmake] [libunwind] LLVM_FOUND isn't always set, so just test ifDon Hinton2018-01-271-1/+1
| | | | | | llvm_setup_rpath() is available instead. llvm-svn: 323601
* [cmake] [libunwind] Call llvm_setup_rpath() when adding shared libraries.Don Hinton2018-01-261-0/+3
| | | | | | | | | Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42461 llvm-svn: 323496
* [libunwind] Create install-unwind-stripped target manuallyShoaib Meenai2017-12-081-3/+11
| | | | | | | This supports using a newer libunwind with an older installation of LLVM (whose cmake modules wouldn't have add_llvm_install_targets). llvm-svn: 320163
* [libunwind] Switch to add_llvm_install_targetsShoaib Meenai2017-11-301-5/+3
| | | | | | | | | This gains us the install-unwind-stripped target, to perform stripping during installation. Differential Revision: https://reviews.llvm.org/D40685 llvm-svn: 319498
* [CMake] Use the variable from the right project in install-unwindMartin Storsjo2017-11-291-1/+1
| | | | llvm-svn: 319299
* [libunwind][CMake] Provide option to disable instalation of the libraryPetr Hosek2017-11-171-3/+12
| | | | | | | | | | | | | | 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
* Abstract rwlocks into a class, provide a SRW lock implementation for windowsMartin Storsjo2017-10-231-0/+1
| | | | | | | | | | | | | | This requires _WIN32_WINNT >= 0x0600. If someone wants to spend effort on supporting earlier versions, one can easily add another fallback implementation based on critical sections, or try to load SRW lock functions dynamically. This makes sure that the FDE cache is thread safe on windows. Differential Revision: https://reviews.llvm.org/D38704 llvm-svn: 316364
* build: use POSITION_INDEPENDENT_CODE instead of -fPICSaleem Abdulrasool2017-10-031-2/+2
| | | | | | | | Rather than hardcode the flag and check if the compiler supports it, use the CMake property to get the right flag spelling for the compiler. This makes it generally more portable. llvm-svn: 314834
* SjLj: make the SjLj implementation more portableSaleem Abdulrasool2017-10-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves the definition of the internal helpers `__Unwind_SjLj_GetTopOfFunctionStack` and `__Unwind_SjLj_SetTopOfFunctionStack` into `Unwind-sjlj.c`. These are not extra functions specific to Apple, but rather are internal implementation details of SjLj support in the LLVM libunwind implementation. This allows us to remove the internal header unwind_ext.h, as these functions are not meant to be used as SPI either. Because they are static, they will be given implicit hidden visibility, but due to the simplicity should get fully inlined into the actual use. Use the C11 standard static TLS annotation (`_Thread_local`) if possible, otherwise, use the Windows specific `__declspec(thread)` when targeting Windows or the GNU `__thread` extension. In theory, it should be possible for this implementation to use a `pthread_setspecific` and `pthread_getspecific` on platforms with pthreads or `SetFlsValue` and `GetFlsValue` on Windows for non-static TLS. However, static TLS tends to be significantly faster, so we really should prefer that over the dynamic TLS approach. On Apple environments, when not building for the loader (dyld), use the pre-allocated TLS slot in the loader rather than the local static TLS variable. Note that the un-threaded support of libunwind is still present as before, however, it is unsafe to use in a threaded environment as the cleanup stack may be mutated incorrectly due to lack of locking across threads. In the static TLS model, the lock is unneeded as each thread of execution retains its own copy of the cleanup stack. Take the opportunity to clean up the comment block, removing the iOS specific note as the SjLj implementation can be used outside of the context of iOS. Convert the rest of the explanation to a doxygen style comment block. llvm-svn: 314632
* [CMake] Allow overriding lib dir suffix independently from LLVMPetr Hosek2017-08-081-2/+2
| | | | | | | | This matches the options already supported by libc++ and libc++abi. Differential Revision: https://reviews.llvm.org/D36383 llvm-svn: 310327
* [libunwind][CMake] Add install path variable to allow overriding the destinationPetr Hosek2017-07-111-2/+2
| | | | | | | | | This is going to be used by the runtime build in the multi-target setup to allow using different install prefix for each target. Differential Revision: https://reviews.llvm.org/D33760 llvm-svn: 307606
* [libunwind] Add support for a single-threaded libunwind buildAsiri Rathnayake2016-09-281-1/+3
| | | | | | | | | | | | | | 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
* Allow building both shared and static libraryPetr Hosek2016-08-081-16/+37
| | | | | | | | | 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
* Attempt to fix libunwind buildEric Fiselier2016-06-021-2/+2
| | | | llvm-svn: 271466
* [libunwind] Allow target flags to affect CMake configuration testsEric Fiselier2016-06-021-3/+6
| | | | | | | | | | | | | | | | | | | | | 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
* unwind: clean up warnings from the buildSaleem Abdulrasool2015-04-251-1/+4
| | | | | | | | | | | | Now thta the build is split, clean up some of the warnings in the build: cc1: warning: command line option '-nostdinc++' is valid for C++/ObjC++ but not for C cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C Append the C++ specific flags specifically to the C++ sources. Avoids the spurious warnings due to invalid flags being passed during the compilation of C++ sources. llvm-svn: 235797
* libunwind: add new build logicSaleem Abdulrasool2015-04-251-61/+52
| | | | | | | This replicates most of the build infrastructure from libc++abi ported to libunwind. This allows building libunwind without requiring libc++abi. llvm-svn: 235795
* unwind: move src/Unwind, include/, and test/ unwind contentSaleem Abdulrasool2015-04-241-0/+118
This moves the majority of the unwind sources into the new project layout for libunwind. This was previously discussed on llvmdev at [1]. This is a purely movement related change, with the build infrastructure currently still residing in the libc++abi repository. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081507.html llvm-svn: 235758
OpenPOWER on IntegriCloud