I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D130948
This makes sure the assertions also get verified in optimized builds.
This matches what is already done in bad_unwind_info.pass.cpp.
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D131210
It must have been a copy-paste error, since cxx-include is never defined
by the libunwind config.
Differential Revision: https://reviews.llvm.org/D131030
By adding noinline and calling fprintf before returning we ensure that
every function will have a distinct call frame and that the return address
will always be saved instead of saving the target in main as the result.
Before this change all backtraces were always backtrace -> main -> _start,
i.e. always exactly three entries. This happenend because all calls were
inlined in main() and the test just happenend to pass because there is at
least _start before main.
I found this while fixing some bugs in libunwind for CHERI and noticed that
the test was passing even though the code was completely broken.
Obtained from: https://github.com/CTSRD-CHERI/llvm-project
Reviewed By: #libunwind, ldionne, MaskRay
Differential Revision: https://reviews.llvm.org/D126611
Summary:
This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX.
Reviewed by: ldionne, MaskRay, libunwind, ibc++abi
Differential Revision: https://reviews.llvm.org/D126017
Add a warning and tweak the release note to explain that the deprecation
targets libc++, libc++abi and libuwnind as well.
Also, as a fly-by, ensure that our CI runs the legacy testing configuration
for libc++, libc++abi and libunwind. This doesn't matter too much since
it's deprecated, but we might as well test it properly.
Differential Revision: https://reviews.llvm.org/D126478
Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already selected correctly by default.
Differential Revision: https://reviews.llvm.org/D126470
We've observed segfaults in libunwind when attempting to check for the
Linux aarch64 sigreturn frame, presumably because of bad unwind info
leading to an incorrect PC that we attempt to read from. Use
process_vm_readv to read the memory safely instead.
The s390x code path should likely follow suit, but I don't have the
hardware to be able to test that, so I didn't modify it here either.
Reviewed By: MaskRay, rprichard, #libunwind
Differential Revision: https://reviews.llvm.org/D126343
The _LIBUNWIND_HAS_NO_THREADS macro is only picked up by libunwind
inside its sources, so it is only required when it builds. It doesn't
need to be defined when running the tests.
Also, add a CI job that tests this configuration. The exact configuration
is that we build a shared libc++ and merge objects for the ABI library
and the unwinder library into it.
Differential Revision: https://reviews.llvm.org/D125903
Program may set the RA_SIGN_STATE pseudo register by expressions.
Libunwind expected only the DW_CFA_AARCH64_negate_ra_state could change the value
of the register which leads to runtime errors on PAC enabled systems.
In the recent version of the aadwarf64[1] a limitation is added[2] to forbid the mixing the
DW_CFA_AARCH64_negate_ra_state with other DWARF Register Rule Instructions.
[1] https://github.com/ARM-software/abi-aa/releases/tag/2022Q1
[2] https://github.com/ARM-software/abi-aa/pull/129
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D123692
Unwinding out of signal handlers currently does not work since
the sigreturn trampoline is not annotated with CFI data.
Fix this by detecting the sigreturn trampoline during unwinding
and providing appropriate unwind data manually. This follows
closely the approach used by existing code for the AArch64 target.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D124765
For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.
Differential Revision: https://reviews.llvm.org/D120851
Instead, folks can use the equivalent variables provided by CMake
to set those. This removal aims to reduce complexity and potential
for confusion when setting the target triple for building the runtimes,
and make it correct when `CMAKE_OSX_ARCHITECTURES` is used (right now
both `-arch` and `--target=` will end up being passed, which is downright
incorrect).
Differential Revision: https://reviews.llvm.org/D112155
It's possible for this test not to pass if the libc used does not provide
unwind info for raise. We can replace it with __builtin_cast, which can lead
to a SIGTRAP on x86_64 and a SIGILL on aarch64.
Using this alternative, a nop is needed before the __builtin_cast. This is
because libunwind incorrectly decrements pc, which can cause pc to jump into
the previous function and use the incorrect FDE.
Differential Revision: https://reviews.llvm.org/D114818
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
When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.
The only caveat with this approach is that we are now relying on the
fact that `-L <path-to-local-libunwind>` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.
This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.
Differential Revision: https://reviews.llvm.org/D114385
Summary:
This patch marks libunwind test case signal_frame.pass.cpp as UNSUPPORTED on AIX because the AIX assembler does not support CFI directives.
Reviewed by: danielkiss, MaskRay, ldionne, libunwind
Differential Revision: https://reviews.llvm.org/D113607
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
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
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
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
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
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
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>
In some binaries, built with clang/lld, libunwind crashes
with "unsupported x86_64 register" for regNum == 16:
Differential Revision: https://reviews.llvm.org/D107919
_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
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
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 necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
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 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
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.
This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.
Differential Revision: https://reviews.llvm.org/D102012
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D97572
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
Differential Revision: https://reviews.llvm.org/D91069
An AArch64 sigreturn trampoline frame can't currently be described
in a DWARF .eh_frame section, because the AArch64 DWARF spec currently
doesn't define a constant for the PC register. (PC and LR may need to
be restored to different values.)
Instead, use the same technique as libgcc or github.com/libunwind and
detect the sigreturn frame by looking for the sigreturn instructions:
mov x8, #0x8b
svc #0x0
If a sigreturn frame is detected, libunwind restores all the GPRs by
assuming that sp points at an rt_sigframe Linux kernel struct. This
behavior is a fallback mode that is only used if there is no ordinary
unwind info for sigreturn.
If libunwind can't find unwind info for a PC, it assumes that the PC is
readable, and would crash if it isn't. This could happen if:
- The PC points at a function compiled without unwind info, and which
is part of an execute-only mapping (e.g. using -Wl,--execute-only).
- The PC is invalid and happens to point to unreadable or unmapped
memory.
In the tests, ignore a failed dladdr call so that the tests can run on
user-mode qemu for AArch64, which uses a stack-allocated trampoline
instead of a vDSO.
Reviewed By: danielkiss, compnerd, #libunwind
Differential Revision: https://reviews.llvm.org/D90898
Gabriel Ravier