If Clang is set up to link directly against libunwind (via the
--unwindlib option, or the corresponding builtin default option),
configuring libunwind will fail while bootstrapping (before the
initial libunwind is built), because every cmake test will
fail due to -lunwind not being found, and linking the shared library
will fail similarly.
Check if --unwindlib=none is supported, and add it in that case.
Using check_c_compiler_flag on its own doesn't work, because that only
adds the tested flag to the compilation command, and if -lunwind is
missing, the linking step would still fail - instead try adding it
to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work.
This avoids having to pass --unwindlib=none while building libunwind.
Differential Revision: https://reviews.llvm.org/D112126
After recent changes to the Docker image, all hell broke loose and the
CI started failing. This patch marks a few tests as unsupported until
we can figure out what the issues are and fix them.
In the future, it would be ideal if the nodes could pick up the Dockerfile
present in the revision being tested, which would allow us to test changes
to the Dockerfile in the CI, like we do for all other code changes.
Differential Revision: https://reviews.llvm.org/D112737
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
Instead of going through libc++'s run.py, we can simply run the executable
directly since we don't need to setup a working directory or control the
environment.
Differential Revision: https://reviews.llvm.org/D112649
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 5a8ad80b6f, which was reverted in
070a2ddcb6 because it broke the Bootstrapping build. This has now been
addressed by tweaking the from-scratch config.
Differential Revision: https://reviews.llvm.org/D112082
We recently introduced a from-scratch config to run the libunwind tests.
However, that config was always looking for libunwind in <install>/lib,
and never in <install>/<target>/lib, which is necessary for tests to
work when the per-target-runtime-dir configuration is enabled.
This commit fixes that. I believe this is what caused the CI failures we
saw after 5a8ad80b6f and caused it to be reverted.
Differential Revision: https://reviews.llvm.org/D112322
In 395271a, I simplified how we handled the target triple for the
runtimes. However, in doing so, we stopped considering the default
in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE
(which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified.
This commit fixes that problem and also refactors the code so that it's
easy to see what the default value is.
The fact that nobody seems to have been broken by this makes me think
that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the
triple -- but it should still work.
Differential Revision: https://reviews.llvm.org/D111672
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.
Differential Revision: https://reviews.llvm.org/D112082
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
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
Instead of always defining LIBCXXABI_NO_TIMER to run the tests, only
define LIBCXXABI_USE_TIMER when we want to enable the timer. This makes
the libc++abi testing configuration simpler.
As a fly-by fix, remove the unused LIBUNWIND_NO_TIMER macro from libunwind.
Differential Revision: https://reviews.llvm.org/D111667
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.
Differential Revision: https://reviews.llvm.org/D110736
We should arguably have always been doing that. The state of libunwind
is quite sad, so this commit adds several XFAILs to make the CI pass.
We need to investigate why so many tests are not passing in some
configurations, but I'll defer that to folks who actually work on
libunwind for lack of bandwidth.
Differential Revision: https://reviews.llvm.org/D110872
Fixes D110144.
registers.getFloatRegister is not const in ARM therefor can't be called here.
Reviewed By: mstorsjo, #libunwind
Differential Revision: https://reviews.llvm.org/D110731
During a backtrace the `.cfi_undefined` for a float register causes an assert in libunwind.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D110144
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
-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107835
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>
The original libunwind project defines UNW_AARCH64_* instead of UNW_ARM64_*.
Rename the enum members to match. This allows some applications with simple
`unw_init_local` usage to migrate to llvm-project libunwind.
Note: the canonical names of `UNW_ARM_D{0..31}` are now `UNW_AARCH64_V{0..31}`,
to match the original libunwind.
UNW_ARM64_* are kept for now for compatibility. Some may be unneeded and can be
cleaned up in the future.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D107996
In some binaries, built with clang/lld, libunwind crashes
with "unsupported x86_64 register" for regNum == 16:
Differential Revision: https://reviews.llvm.org/D107919
-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107835
_Unwind_ForcedUnwind is not mandated by the EHABI but for compatibilty
reasons adding so the interface to higher layers would be the same.
Dropping EHABI specific _Unwind_Stop_Fn definition since it is not defined by EHABI.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D89570
Moving Itanium and ArmEHABI specific implementations to dedicated files.
This is a NFC patch.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D106461
Currently, OR1K architecture put the program counter at offset 0x128 of
the current `or1k_thread_state_t`. However, the PC is restored after
updating the thread pointer in `r3`, which causes the PC to be fetched
incorrectly.
This patch swaps the order of restoration of `r9` and `r3`, such that
the PC is restored to `r9` using the current thread state.
Patch by Oi Chee Cheung!
Reviewed By: whitequark, compnerd
Differential Revision: https://reviews.llvm.org/D107042
Building the libraries with -fPIC ensures that we can link an executable
against the static libraries with -fPIE. Furthermore, there is apparently
basically no downside to building the libraries with position independent
code, since modern toolchains are sufficiently clever.
This commit enforces that we always build the runtime libraries with -fPIC.
This is another take on D104327, which instead makes the decision of whether
to build with -fPIC or not to the build script that drives the runtimes'
build.
Fixes http://llvm.org/PR43604.
Differential Revision: https://reviews.llvm.org/D104328
This is a NFC commit to normalize how we set target properties on the
various runtime targets. A follow-up patch is going to add new properties,
and I wanted that follow-up patch to be cleaner.
This commit modifies stepWithDwarf allowing for CFI directives to
specify the value of the stack pointer.
Previously, the SP would be unconditionally set to the CFA, because it
(wrongly) stated that the CFA is the stack pointer at the call site of a
function, but that is not always true.
One situation in which that is false, is for example if you have
switched stacks. In that case if you set the CFA to the SP before
switching the stack, the CFA would be far away from where the current
call frame is located.
The CFA always points to the current call frame, and that call frame
could have a CFI directive that specifies how to restore the stack
pointer. If not, it is OK to fallback and set the SP = CFA.
This change sets SP = CFA before restoring the registers during
unwinding, allowing the stack frame to be restored with a value
different than the CFA.
Reviewed By: #libunwind, phosek
Differential Revision: https://reviews.llvm.org/D106626
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.
This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.
Differential Revision: https://reviews.llvm.org/D106009
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.
This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.
One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.
Differential Revision: https://reviews.llvm.org/D106082
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.
So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.
For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.
Differential Revision: https://reviews.llvm.org/D105991
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.
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 38b2dec37e 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
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
"bad second level page" and "second level compressed unwind table"
can now be grepped for.
(Also remove one of the two spaces between "second" and "level"
in the second message.)
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.
Differential Revision: https://reviews.llvm.org/D105047
Fix for the following exception.
AttributeError: 'TestingConfig' object has no attribute 'target_triple'
Related revision: https://reviews.llvm.org/D102012
'TestingConfig' object has no attribute 'target_triple'
Reviewed By: #libunwind, miyuki, danielkiss, mstorsjo
Differential Revision: https://reviews.llvm.org/D103140
This was regressed in adf1561d6c. Since gcc does not support
`__has_feature`, this adjusts the build to use the
`__SANITIZE_ADDRESS__` macro which GCC defines to identify if ASAN is
enabled (similar to `__has_feature`). This allows building libunwind
with gcc again.
Patch by Daniel Levin!
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D104176
This matches the fact that we build the experimental library by default.
Otherwise, by default we'd be building the library but not testing it,
which is inconsistent.
Differential Revision: https://reviews.llvm.org/D102109
Martin Storsjö