Similar to D90898 (Linux AArch64), D124765 (SystemZ), and D148499
(RISCV).
In this commit, I enabled two test cases, while zhuqizheng supported
with the source code development.
Co-Authored-By: zhuqizheng <zhuqizheng@loongson.cn>
Co-authored-by: zhuqizheng <zhuqizheng@loongson.cn>
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
Instead of placing artifacts for testing the runtimes at <build>/test,
place those artifacts at <build>/<project>/test. This prevents
cluttering the build directory with the runtimes' test artifacts for
everyone else.
As a drive-by, remove LIBCXX_BINARY_INCLUDE_DIR which wasn't used
anymore.
`__xlcxx_personality_v0` is the personality routine in `libc++abi` for
the EH of applications generated by the legacy IBM C++ compiler. Since
the EH info generated by the legacy compiler does not provide the
location of the personality routine, this routine is hard-coded as the
handler for legacy EH in the unwinder. The symbol is resolved
dynamically using `dlopen()` to avoid a hard dependency of `libunwind`
on `libc++abi` for cases such as non-C++ applications. The weak
declaration of `__xlcxx_personality_v0` was originally intended to
bypass `dlopen()` if the C++ application generated by the legacy
compiler is statically linked with the new LLVM C++ compiler.
Unfortunately, this causes problems with runtime linking for
Clang-compiled code using the unwinder that does not link with
`libc++abi`.
On the other hand, the C++ runtime libraries shipped for AIX are
actually stripped and statically linking is not supported. So, we can
fix the problem by removing the `__xlcxx_personality_v0` weak
declaration. Besides, `dlopen()` would work as long as the libc++abi
shared library is available.
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
This is what we started doing in libc++ and it straightens up a lot of
things that only happened to work before, notably the presence of
relative rpaths in dylibs when running from the build tree.
This unlocks the ability to link against a just-built dylib but run
against another version of the dylib (for example the system-provided
one), which is necessary for proper backdeployment testing.
This patch adds a lot of code duplication between the libc++ and
libc++abi testing setups. However, there is already a large amount of
duplication and the only real way to get rid of it is to merge libc++abi
into libc++. In a way, this patch is a step in that direction because it
closes the gap between the two libraries' testing setup.
AArch64 GCS (Guarded Control Stack) is similar enough to CET that we can
re-use the existing code that is guarded by _LIBUNWIND_USE_CET, so long
as we also add defines to locate the GCS stack and pop the entries from
it. We also need the jumpto function to exit using br instead of ret, to
prevent it from popping the GCS stack.
GCS support is enabled using the LIBUNWIND_ENABLE_GCS cmake option. This
enables -mbranch-protection=standard, which enables GCS. For the places
we need to use GCS instructions we use the target attribute, as there's
not a command-line option to enable a specific architecture extension.
Patch [llvm#92291](https://github.com/llvm/llvm-project/pull/92291)
causes wrong traceback from a signal handler for AIX because the AIX
unwinder uses the traceback table at the end of each function instead of
FDE/CIE for unwinding. This patch adds a condition to exclude traceback
table based unwinding from the code added by the patch.
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes#82107
We can't use `dladdr()` in the tests, because when we're statically
linking with musl that function is a no-op.
Additionally, because musl disables emission of unwind information in
its build, and because its signal trampolines don't include unwind
information, tests that involve unwinding through a signal handler won't
work and need to be disabled for musl.
rdar://123436891
Instead of using FOO_TEST_DEPS global variables that don't get updated
properly from subdirectories, use targets to propagate the dependencies
across directories.
A while back, the cxx_under_test Lit parameter was removed. This patch
reintroduces a Lit parameter called "compiler" which controls the value
of the %{cxx} substitution used in the test suite.
To run the test suite with a different compiler, one can now pass
--param compiler=<path>.
This patch adds a configuration of the libc++ test suite that enables
optimizations when building the tests. It also adds a new CI
configuration to exercise this on a regular basis. This is added in the
context of [1], which requires building with optimizations in order to
hit the bug.
[1]: https://github.com/llvm/llvm-project/issues/68552
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.
Differential Revision: https://reviews.llvm.org/D154246
libunwind uses a minimal set of necessary standard library functions,
basically just `memset` and `memcpy`. There is a single use of `strcpy`
to copy the bytes `"CLNGUNW"` into a `uint64_t` object. This is both an
arguably odd use of the `strcpy` function as well as it unnecessarily
widens the set of library functions that must be available to build
libunwind, which can be an obstacle in baremetal scenarios. This change
simply replaces this one `strcpy` with the more fundamental `memcpy`.
This will allow for configuring tests according to AIX version.
Reviewed By: daltenty, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D149660
Summary:
The implementation of AIX unwinder gets the return address from the link area of the stack frame of a function and uses the return address to walk up functions. However, when unwinding starts from a signal handler and the function that raised the signal happens to be a leaf function and it does not have its own stack frame, the return address of the stack frame of the leaf function points to the caller of the function that calls the leaf function because the leaf function and its caller share the same stack frame. As a result, the caller of the leaf function is skipped. This patch fixes the problem by saving the LR value in sigcontext when the unwinder hits the signal handler trampoline frame and using it as the return address of the leaf function. The LR value from sigcontext is saved in the unwinding context slot for LR currently unused.
Reviewed by: stephenpeckham
Differential Revision: https://reviews.llvm.org/D158655
Since 78d649a417b48cb8a2ba2e755f0e7c8fb8b1bb83 the recommended way to
pass an executor is to use the _TEST_PARAMS variable, which means we now
pass more complicated value (including ones that may contain multiple
`=`) as part of this variable. However, the `REGEX REPLACE` being used
has greedy matches so everything up to the last = becomes part of the
variable name which results in invalid syntax in the generated lit
config file.
This was noticed due to builder failures for those using the
CrossWinToARMLinux.cmake cache file.
---------
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
This is useful when trying to run multiple tests with different
arguments to the executor script. This is needed in my case since I
do not know the correct ssh connection arguments when building libc++.
The testing script I have spawns multiple QEMU instances that listen on
a given port on localhost and runs lit with the --num-shards/--run-shard
argument. In order to connect each shard to the right QEMU instances I
need to customize the arguments passed to ssh.py (--extra-ssh-args and
--extra-scp-args) but can't do this at configure time since the target
port is only known when running the tests but not when calling CMake.
This change allows me to pass `executor=ssh.py <args>` to lit once I
know
the right hostname/port for running the tests.
This also deprecates the `LIB{CXX,CXXABI,UNWIND}_EXECUTOR` CMake
variable
as the same can be achieved by adding `executor=...` to the
`LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS` variable.
I was trying to run the tests on FreeBSD and noticed that we weren't
printing symbol names. It turns out this is because of the missing
-Wl,--export-dynamic flag. Instead of hardcoding the name of the flag
and only passing it for Linux hosts, use a pre-existing CMake variable
instead. I was not aware of this flag, but it appears to have been
supported for the past 16 years (with support for more platforms added
later):
66d1930f56
`unw_getcontext` saves the caller's registers in the context. However,
if the caller of `unw_getcontext` is in a different module, the glue
code of `unw_getcontext` sets the TOC register (r2) with the new TOC
base and saves the original TOC register value in the stack frame. This
causes the incorrect TOC value is used when the caller steps up frames,
which fails libunwind LIT test case `unw_resume.pass.cpp`. This PR fixes
the problem by using the original TOC register value saved in the stack
if the caller is in a different module and enables `unw_resume.pass.cpp`
on AIX.
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
On Windows, the PATH env variable is used for locating dynamically
linked librarys, akin to LD_LIBRARY_PATH on Linux.
The tests that run with a dynamically linked libc++ used "--env
PATH=%{lib}" in the test config. This had the unfortunate side effect
of making other tools from PATH unavailable during the runtime of the
tests; in particular, it caused the "executor-has-no-bash" flag to be
set for all those Windows test configs (with the clang-cl static config
being the only one lacking it).
Thus, this increases the number of tests actually included in the
clang-cl dll and all mingw test configs by 9 tests.
The clang-cl static test configuration has been executing those tests
since the "--env PATH=%{lib}" was removed from that test config in
e78223e79efc886ef6f0ea5413deab3737d6d63b. (For mingw we haven't had a
need to split the test config between shared and static, which means
that the mingw static test config previously ran with --env PATH
needlessly.)
This increases the test coverage for patches like D146398 which
can't be executed in the executor-has-no-bash configs.
Change the default value of the arg.env to an empty array; when we do
pass values to the option, they get passed as an array of strings,
so make sure the variable behaves consistently when no arguments
have been passed.
Differential Revision: https://reviews.llvm.org/D148324
Previously, all the output from the tests were placed directly in
the build directory. The tests produce a couple directories named
`__config_{exec,cache,src}__` which are easy to distinguish, and
the output from the individual tests were placed directly in a
directory named `Output`.
This is the same change as
736c6e246f5398331d83edd204a846cc967ad5c6, but for the libcxxabi
and libunwind test suites.
Differential Revision: https://reviews.llvm.org/D147628
Mark it as unsupported on x86_64, arm and aarch64. On i686, DWARF
is used as the default unwinding format, and there, the CFI
directives are supported.
Differential Revision: https://reviews.llvm.org/D147858
$ra should be restored before $a0, otherwise the baseaddress ($a0) would
be destroyed. See file `UnwindRegistersSave.S` for reference.
This also makes libcxx and libcxxabi regtest pass for the `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` build.
Reviewed By: MaskRay, xen0n, #libunwind
Differential Revision: https://reviews.llvm.org/D147372
This is here for local unwinding, which unw_resume() restores
the machine state and then directly resumes execution in the
target stack frame.
Reviewed By: wangleiat
Differential Revision: https://reviews.llvm.org/D147371
This is the same as c218c80c730a14a1cbcebd588b18220a879702c6,
but for libcxxabi and libunwind.
This fixes running tests on Windows with Python installed in
e.g. "C:\Program Files\Python38".
Differential Revision: https://reviews.llvm.org/D147629
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
Fix#60472
The testcase is writen in all inline asm but it seems not well
maintained for the CFI directive, of cause we can fix that, but this
patch also contain another issue is it use s0 and s1 without
store/restore.
This patch proposed another way to testing that, use inline asm to
generate dummy def and use, so compiler will generate store/restore for
the vector register, and then generate the CFI directives.
Also check __riscv_vector as the testcase guard, because the testcase
will read vlenb which is only available when V or zve* extensions is
present.
Reviewed By: MaskRay, asb, #libunwind
Differential Revision: https://reviews.llvm.org/D145225
Support reading of VLENB (vector byte length) control register, that can be
required for correct unwinding of RVV objects on stack.
Differential Revision: https://reviews.llvm.org/D136264
This reverts commit bec8a372fc0db95852748691c0f4933044026b25.
This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:
ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64
This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.
This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default,
but using a separate variable allows additional normalization to be
performed if needed.
Differential Revision: https://reviews.llvm.org/D137451
Now that all jobs have moved over to the new style of Lit configuration,
we can remove all traces of the legacy testing configuration system.
This includes:
- Cache settings that are not honored or useful anymore
- Several CMake options that were only useful in the context of the
legacy Lit configuration system
- A bunch of Python support code that is not used anymore
- The legacy lit.cfg.in files themselves
Differential Revision: https://reviews.llvm.org/D134650
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
