After this change, we need to explicitly list the languages the
project uses, otherwise the assembly source files won't get built
at all.
Previously (before that commit), the assembly source files were
simply treated as C.
The toplevel llvm CMakeLists.txt adds these three languages, so
when building libunwind integrated as part of that, it works fine.
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 938c70b86c).
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
This reverts commit b3fdf33ba6.
This change broke building libunwind for Windows/MinGW, and broke
on aspect of the CMake tests in libunwind in general.
After set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), CMake
skips the linking step in tests, but cmake/config-ix.cmake also
does a few checks for functions in libraries (looking for whether
-lc provides fopen and whether -ldl provides dladdr).
As CMake only tests building a static library, these tests
incorrectly succeed and CMake concludes "Looking for fopen in c -
found" and "Looking for dladdr in dl - found", while building
then fails at the end with errors about unable to find -lc and -ldl.
Summary:
Or, rather, don't accidentally forget to pass it.
This is aimed to solve the problem discussed in [this thread](http://lists.llvm.org/pipermail/llvm-dev/2019-November/136890.html), and to fix [a year-old bug](https://bugs.llvm.org/show_bug.cgi?id=38468).
TL;DR: when building libunwind for ARM Linux, we **need** libunwind to be built with the `-funwind-tables` flag, because, well ARM EHABI needs unwind info produced by this flag. Without the flag all the procedures in libunwind are marked `.cantunwind`, which causes all sorts of bad things. From `_Unwind_Backtrace` not working, to C++ exceptions not being caught (which is the aforementioned bug is about).
Previously, this flag was not added because the CMake check `add_compile_flags_if_supported(-funwind-tables)` produced a false negative. Why? With this flag, the compiler generates calls to the `__aeabi_unwind_cpp_pr0` symbol, which is defined in libunwind itself and obviously is not available at configure time, before libunwind is built. This led to failure at link time during the CMake check. We handle this by disabling the linker for CMake checks in linbunwind.
Also, this patch introduces a lit feature `libunwind-arm-ehabi`, which is used to mark the `signal_frame.pass.cpp` test as unsupported (as was advised by @miyuki in D70397).
Reviewers: peter.smith, phosek, EricWF, compnerd, jroelofs, saugustine, miyuki, jfb
Subscribers: mgorny, kristof.beyls, christof, libcxx-commits, miyuki
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70815
996e62eef7 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
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 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
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
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
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
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
If we're not in a standalone build, this variable should be already
set, so there's no need to set it again or to cache it.
Differential Revision: https://reviews.llvm.org/D57993
llvm-svn: 353915
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
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
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
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: 352384
When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.
Differential Revision: https://reviews.llvm.org/D56981
llvm-svn: 351875
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
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
This should resolve the breakage introduced in r337867 which introduced
the use of cmake_dependent_option without include the necessary file.
llvm-svn: 337868
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
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48353
llvm-svn: 335169
Summary:
This is done via new LIBUNWIND_TEST_COMPILER_FLAGS and
LIBUNWIND_TEST_LINKER_FLAGS variables.
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D43585
llvm-svn: 326223
When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake
recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
globally which means find_path() always prepends CMAKE_SYSROOT or
CMAKE_FIND_ROOT_PATH to all paths used in the search.
However, this find_path() invocation is looking for a path in the
libcxx project on the host system, not the target system,
which can be done by passing NO_CMAKE_FIND_ROOT_PATH.
Differential Revision: https://reviews.llvm.org/D41621
llvm-svn: 323141
This follows the setup used by other runtimes and is expected by
the lit configuration.
Differential Revision: https://reviews.llvm.org/D40820
llvm-svn: 319830
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
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
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
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
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. The compile
flag handling had a typo which caused these flag not to be properly
include. We also don't have to pass the target triple when checking
for compiler-rt since that flag is already included in compile flags
now.
Differential Revision: https://reviews.llvm.org/D32071
llvm-svn: 300419
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
Martin Storsjö