These are my initial build and code changes to supporting building llvm
as shared library/DLL on windows(without force exporting all symbols)
and making symbol visibility hidden by default on Linux which adding
explicit symbol visibility macros to the whole llvm codebase.
Updated cmake code to allow building llvm-shlib on windows by appending
/WHOLEARCHIVE:lib to the linker options.
Remove the hardcoded CMake error from using LLVM_BUILD_LLVM_DYLIB on
windows.
Updated CMake to define new macros to control conditional export macros
in llvm/Support/Compiler.h
Use /Zc:dllexportInlines- when compiling with clang-cl on windows with a
opt out CMake option to disable using it.
Replace some use of LLVM_EXTERNAL_VISIBILITY with new export macros.
Some of the cmake and code changes are based on @tstellar's earlier PR
https://github.com/llvm/llvm-project/pull/67502.
I have Windows building using clang-cl, while for MSVC its at-least able
to build libllvm, but some tests can't build because llvm iterator
template metaprogramming that doesn't work well with dllexport. Linux
should build without issue. My full branch is here
https://github.com/fsfod/llvm-project/tree/llvm-export-api-20.0 and
including all the auto generated export macros from clang tooling based
system.
Exporting symbols from tools directory never worked with
`LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=On`. When that options is on, only
symbols from the static library is linked is exported due to the export
symbols computation script. DynamicLibraryTests needs to export a symbol
from the tools/executable directory, so update it to use export list
instead.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
CMake -GXcode would otherwise offer to create one scheme for each
target, which ends up being a lot. For now, limit the default to the
`check-*` LIT targets, plus `ALL_BUILD` and `install`.
For targets that aren't in the default list, we now have a configuration
variable to promote an extra list of targets into schemes, for example
`-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to
add schemes for `TargetParserTests` and `SupportTests` respectively.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
* It is possible to setup llvm-project builds without going through
`llvm/CMakeList.txt` so the fatal error handling should be smarter.
* Disable option on Apple style lldb-linux builds.
Building the Apple way turns off plugin support, meaning we don't need
to export unloadable symbols from all executables. While deadstripping
effects aren't expected to change, enabling this across all tools
prevents the creation of export tries. This saves us ~3.5 MB in just the
universal build of `clang`.
Since LLVM supports `-ffat-lto-objects` we should enable this as an
option in the LLVM build. FatLTO should improve the time it takes to
build tests for LTO enabled builds of the compiler by not linking w/ the
bitcode portion of the object files, which should speed up build times
for LTO builds without disabling optimizations.
ld: warning: ignoring duplicate libraries:
This triggers quite frequently in llvm's build because CMake's library
depends mechanism doesn't de-duplicate libraries on the link line.
Duplication is necessary for ELF platforms, but means something subtly
different on Darwin platforms, hence the warning. Since we don't have
much control over that from CMake, just disable the warning wholesale
whenever the linker is detected to support it.
Summary:
Turns out that we need this for the header install directory. I didn't
notice because I had old values cached. Revert for now until I think of
a better way to suppress the error.
Summary:
I've begun treating GPU runtimes builds as cross-compiling with the LLVM
infrastructure. However, we include a lot of random stuff that the GPU
build isn't prepared to handle. This currently emits a warning, and
while it's not striclty necessary, is annoying. This patch suppresses it
by not including the standard GNU install directory resources when used
from the GPU.
1. Replace the obsolete `llvm_add_unittests()` CMake function with an
explicit check for `TARGET llvm_gtest`. This is more consistent with the
rest of the code, and it makes it possible to avoid checking out
`third-party` tree.
2. Add `LLDUnitTests` test dependency to standalone builds. It is
defined unconditionally, and actually necessary to ensure that unit
tests will be built.
Currently `add_lit_target` sets the `USES_TERMINAL` CMake option. When
using Ninja, this forces all lit testsuite targets into the
single-threaded `console` pool.
This PR adds a new option `LLVM_PARALLEL_LIT` which drops the
`USES_TERMINAL` flag, allowing Ninja to run them in parallel.
The default setting (`LLVM_PARALLEL_LIT=OFF`) retains the existing
behavior of serial testsuite execution.
This symlink was added in 91a384621e5b762d9c173ffd247cfeadd5f436a2 to
maintain backwards compatibility, but it needs to point to
libLLVM.so.$MAJOR.$MINOR rather than libLLVM.so. This works better for
distros that ship libLLVM.so and libLLVM.so.$MAJOR.$MINOR in separate
packages and also prevents mistakes like
libLLVM-19.so -> libLLVM.so -> libLLVM.so.18.1
Fixes#82647
We need to do this now that we are bumping the minor release number when
we create the release branch.
This also results in a slight change to the library names for LLVM. The
main library now has a more convential library name:
'libLLVM.so.$major.$minor'. The old library name: libLLVM-$major.so is
now a symlink that points to the new library. However, the symlink is
not present in the build directory. It is only present in the install
directory.
The library name was changed because it helped to keep the CMake changes
more simple.
Fixes#76273
illumos has an older version of the Solaris linker that does not
support the GNU version script compat nor version scripts and does
not support -Bsymbolic-functions. Treat illumos linker separately.
The libclang/CMakeLists part lifted from NetBSD's pkgsrc.
Build tested on Solaris 11.4 and OpenIndiana 2023.10.
/usr/bin/ld --version
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3260
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1790 (illumos)
This adds dlltool to the list of tools which don't get excluded from
installation when LLVM_INSTALL_TOOLCHAIN_ONLY is set.
The most important effect here is that this tool will now be included in
the official Windows release.
While llvm-lib reuses the dlltool machinary internally and has many of
the same capabilities, it does not expose the functionality controller
by the '-k' flag, which is currently the only way to create import
libraries for i386 with stdcall symbols from a module definition alone.
We avoid changing llvm-lib tool, since it is designed to emulate LIB.EXE
from MSVC toolchain, and as this functionality is not supported there,
we would have had to introduce an LLVM extension flag in order to
support it.
See https://reviews.llvm.org/D36548 for reference on rationale for
dlltool '-k' flag.
`CMAKE_{C/CXX}_FLAGS` affects all targets in LLVM. This can
be undesirable in situations, like the case of enabling thinLTO,
where `-flto` is added to every source file. In reality, we only
care about optimizing a select few of binaries, such as clang or lld,
that dominate the compilation pipeline. Auxiliary binaries in a
distribution and not on the critical path can be kept non-optimized.
This PR adds support of per-target linker flags, which can solve the
thinLTO problem by negating the effects of LTO via targeted linker
flags on the targets. The example of negating thinLTO
above can be done by doing the following:
```
set(LLVM_llvm-dwarfdump_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to llvm-dwarfdump")
set(LLVM_lldb_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to lldb")
```
There's other applications where this could be used (e.g. avoid
optimizing host tools for build speed improvement etc.).
I've generalized this so that users can apply their desired flags to
targets that are generated by `llvm_add_library` or
`add_llvm_executable`.
Internally, our toolchain builds were on average 1.4x faster when
selectively choosing the binaries that we want optimized.
This cmake rule is used by external clients, who may or may not have
the LLVM_LIBRARY_OUTPUT_INTDIR variable set.
If it is not set, then we pass `-Wl,-rpath-link,` to the compiler. It
turns out that gcc and clang interpret this differently.
* gcc passes `-rpath-link ""` to the linker, which is what we want.
* clang passes `-rpath-link` to the linker. This is not what we want,
because then the linker gobbles the next command-line argument,
whatever it happens to be, and uses it as the -rpath-link target.
Fix this by passing -rpath-link only if we actually have a path we want.
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
Running lit tests on Windows can fail because its use of
`os.path.realpath` expands substitute drives, which are used to keep
paths short and avoid hitting MAX_PATH limitations.
Changes lit logic to:
Use `os.path.abspath` on Windows, where `MAX_PATH` is a concern that we
can work around using substitute drives, which `os.path.realpath` would
resolve.
Use `os.path.realpath` on Unix, where the current directory always has
symlinks resolved, so it is impossible to preserve symlinks in the
presence of relative paths, and so we must make sure that all code paths
use real paths.
Also updates clang's `FileManager::getCanonicalName` and `ExtractAPI`
code to avoid resolving substitute drives (i.e. resolving to a path
under a different root).
How tested: built with `-DLLVM_ENABLE_PROJECTS=clang` and built `check-all` on both Windows
Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir
Patch by Tristan Labelle <tristan@thebrowser.company>!
Add an option to specify additional linker flags for unit tests only.
For example, this allows using something like
-DLLVM_UNITTEST_LINK_FLAGS="-Wl,-plugin-opt=O0" if you're doing LTO
builds, or -DLLVM_UNITTEST_LINK_FLAGS="-fno-lto" if you're using
fat LTO objects.
The build system already does this itself if the LLVM_ENABLE_LTO
flag is used, but this does not cover all possible LTO configurations.
Differential Revision: https://reviews.llvm.org/D154212
This reverts commit f55fd19b6b565827af5fbf504952dcc35b8b7360.
As noted on the original thread, other uses of LLVM_LIBRARY_OUTPUT_INTDIR are optional. Will make a separate patch that makes this use optional as well.
It looks like MLIR is using the more modern CMAKE_LIBRARY_OUTPUT_DIRECTORY, but AddLLVM still uses this older LLVM specific alias.
In the specific case I was running into, the empty variable was causing `-Wl,-rpath-link,` on the command line, causing the following argument to be swallowed. This was maddening, because the following argument was the .o file containing `main` and I was getting `main` undefined errors when it was clearly there. This is egregious enough that I chose to guard it.
Differential Revision: https://reviews.llvm.org/D153373
This reverts commit aa495214b39d475bab24b468de7a7c676ce9e366.
As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch
allows for using LLD-as-a-lib. It also lets clients link only the drivers that
they want (see unit tests).
This also adds the unit test infra as in the other LLVM projects. Among the
test coverage, I've added the original issue from @krzysz00, see:
https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction
Important note: this doesn't allow (yet) linking in parallel. This will come a
bit later hopefully, in subsequent patches, for COFF at least.
Differential revision: https://reviews.llvm.org/D119049
This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true automatically builds LLVM libc in overlay mode and links all
generated executables against the libc overlay. This is intended to
somewhat mirror the LLVM_ENABLE_LIBCXX flag.
Differential Revision: https://reviews.llvm.org/D151013
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:
* System tools may not be able to handle the target format in case of
cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
of the script code.
The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.
Differential Revision: https://reviews.llvm.org/D149119
Recent commit 8f833f88ab modified the installation rpath and did not set `BUILD_WITH_INSTALL_RPATH` correctly on AIX, which led to installation failures on AIX. This patch sets `BUILD_WITH_INSTALL_RPATH` on AIX to fix the installation failures.
Reviewed By: buttaface, daltenty
Differential Revision: https://reviews.llvm.org/D148866
If any LLVM subprojects are built separately, the LLVM build directory
LLVM_LIBRARY_DIR is added to both the build and install runpaths in
llvm_setup_rpath(), which is incorrect when installed. Separate the
build and install runpaths on ELF platforms and finally remove the
incorrect call to this function for compiler-rt, as previously attempted
in 21c008d5a5b. That prior attempt was reverted in 959dbd1761c, where it
was said to break the build on macOS and Windows, so I made sure to keep
those platforms the same.
Two examples of incorrect runpaths that are currently added, one from
the latest LLVM 16 toolchain for linux x86_64:
> readelf -d clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.*so | ag "File:|runpath"
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.dyndd.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan_aliases.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.memprof.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.scudo_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.tsan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_minimal.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
Another is in the Swift toolchain, which builds lldb separately:
> readelf -d swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/{bin/lldb*,lib/liblldb.so}|ag "File:|runpath"
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-argdumper
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-server
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/lib/liblldb.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib:/home/build-user/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux:$ORIGIN/../lib/swift/linux]
This patch should fix this problem of absolute paths from the build host
leaking out into the toolchain's runpaths.
Differential revision: https://reviews.llvm.org/D146918
When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.
The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.
LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.
In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.
The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.
Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.
This fixes
https://github.com/llvm/llvm-project/issues/60784.
Differential Revision: https://reviews.llvm.org/D146666
The change to potentially use symlinks on Windows was added in
https://reviews.llvm.org/D99170.
LLVM_USE_SYMLINKS was added more recently in
https://reviews.llvm.org/D135578 and allows specifying at configure time
whether or not symlinks should be created. The benefit of using this
option is it allows building the package on a symlink-capable Windows
machine with symlinks disabled so that the resulting package can be used
on a Windows machine that doesn't support symlinks.
Differential Revision: https://reviews.llvm.org/D145443
In D61448 the cmake option `LLVM_ENABLE_UNWIND_TABLES` was added.
Despite the name suggesting that the option enables unwind tables, that
patch only uses it to disable them. That makes a difference for
architectures where unwind tables aren't enabled by default. The lack of
unwind tables impacts backtraces and the current handling of the option
doesn't allow enabling them. This patch makes an ON value of
`LLVM_ENABLE_UNWIND_TABLES` actually enable unwind tables.
Differential Revision: https://reviews.llvm.org/D144178
