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
We only initialize a few fields in DISPATCHER_CONTEXT - don't leave
the rest in an uninitialized state; make sure the whole struct is
in a deterministic state.
This makes nondeterministic failures deterministic, for some cases
relating to forced unwinding on aarch64/arm (which requires filling
in parsing of the xdata for finding the exception handler and LSDA).
Differential Revision: https://reviews.llvm.org/D148660
Unwind_AppleExtras.cpp contained annotations telling the linker that
some symbols are not available on some very old platforms. However,
those platforms are not supported anymore, so the annotations are not
used.
Why remove this? In addition to cleaning up the code base, this also
removes the possibility of implementing those annotations incorrectly
(which was the case previously), which could lead to important symbols
being hidden when they should have been visible.
Differential Revision: https://reviews.llvm.org/D148445
When we initialize the UnwindCursor (unw_cursor_t) based on
an existing Registers object (unw_context_t), we only initialize
a subset of the class.
Fill the struct properly for the current thread with RtlCaptureContext,
followed by overwriting of the subset of registers that we do have
available in the Registers class.
One might think that it's enough to initialize specifically the
registers that we signal availability for with ContextFlags,
however in practice, that's not enough.
This fixes crashes when restoring the context via RtlRestoreContext
(via UnwindCursor::jumpto), via __unw_resume.
Differential Revision: https://reviews.llvm.org/D147636
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
This fixes the libcxxabi test force_unwind3.pass.cpp when run on native
Windows.
When unwinding past the main thread function into the system functions
that brought up the thread, we can hit functions whose personality
functions return ExceptionContinueExecution (instead of the regular
ExceptionContinueSearch). Interpret this as a signal to stop the
unwind.
Curiously, in this case, it does return ExceptionContinueSearch if
running within a debugger.
Differential Revision: https://reviews.llvm.org/D147739
For normal C++ unwinding, we get _dispContext initialized by the
prepopulated DISPATCHER_CONTEXT in _GCC_specific_handler, which
we set with __unw_seh_set_disp_ctx.
When doing force unwinding, we step and populate the unw_proc_info_t
struct _info with getInfoFromSEH, but when we execute the handler
via the __libunwind_seh_personality wrapper function, we execute
the handler set in DISPATCHER_CONTEXT.
Whenever updating these fields in either _info or _dispContext,
sync them to the other one too.
This fixes one aspect of the libcxxabi force_unwind*.pass.cpp tests on
x86_64.
Differential Revision: https://reviews.llvm.org/D147637
For x86_64 Windows targets (that use SEH), _LIBUNWIND_CURSOR_SIZE
is 204; this fixes corruption in test cases that include libunwind.h
without manually defining _LIBUNWIND_IS_NATIVE_ONLY.
If the libunwind.h header is included without defining
_LIBUNWIND_IS_NATIVE_ONLY (like in the libunwind test cases), the
sizes are set to accommodate the maximum possible cursors and
contexts.
(Alternatively, __libunwind_config.h should be changed to default
to native unwinding unless cross unwinding has been requested.
Cross unwinding isn't implemented as far as I know anyway.)
Differential Revision: https://reviews.llvm.org/D147634
$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
In most configs, stderr is line buffered by default, but in some
cases on Windows (running in git bash, or running in Wine) stderr
can end up fully buffered.
See 2ec75a0869ab01fa9caf310e8a31eb7716182d30 for a similar change
for the output from lit itself.
This has no effect on libunwind when the log messages aren't enabled
via the environment variables.
Differential Revision: https://reviews.llvm.org/D147632
This typo (unw_step instead of unw_get_proc_info) has been around since
the initial public commit of libunwind.
Differential Revision: https://reviews.llvm.org/D147631
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
Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module and use angle includes to include them.
Reviewed By: ldionne, #libunwind
Differential Revision: https://reviews.llvm.org/D144323
GNU assembler mandates armv8.5-a for memtag instructions. Maybe
we should remove this restriction in GNU assembler, but let's work
around it for current GNU Binutils releases.
Differential Revision: https://reviews.llvm.org/D146109
This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind.
Reviewed By: ldionne, #libunwind, #libc, #libc_abi
Spies: mikhail.ramalho, phosek, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144252
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
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
These have the same purposes but two different implementations.
llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects
flags used both for compilation and linking which is problematic because
some flags may be link-only and trigger unused argument warning when set
during compilation. llvm_check_linker_flag does not have this issue so
we chose it as the prevailaing implementation.
Differential Revision: https://reviews.llvm.org/D143052
Currently, libunwind just uses stxvd2x/lxvd2x to save/restore
VSX registers respectively. This puts the registers in
doubleword-reversed order into memory on little endian systems.
If both the save and restore are done the same way, this
isn't a problem. However if the unwinder is just restoring
a callee-saved register, it will restore it in the wrong
order (since function prologues save them in the correct order).
This patch adds the necessary swaps before the saves and after
the restores.
Differential revision: https://reviews.llvm.org/D137599
This commit adds support for a new callback-based lookup scheme for unwind
info that was inspired by the `_dyld_find_unwind_info_sections` SPI that
libunwind uses to find unwind-info in non-JIT'd frames. From
llvm-project/libunwind/src/AddressSpace.hpp:
```
struct dyld_unwind_sections {
const struct mach_header* mh;
const void* dwarf_section;
uintptr_t dwarf_section_length;
const void* compact_unwind_section;
uintptr_t compact_unwind_section_length;
};
extern bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
```
During unwinding libunwind calls `_dyld_find_unwind_sections` to both find
unwind section addresses and identify the subarchitecture for frames (via the
MachO-header pointed to by the mh field).
This commit introduces two new libunwind SPI functions:
```
struct unw_dynamic_unwind_sections {
unw_word_t dso_base;
unw_word_t dwarf_section;
size_t dwarf_section_length;
unw_word_t compact_unwind_section;
size_t compact_unwind_section_length;
};
typedef int (*unw_find_dynamic_unwind_sections)(
unw_word_t addr, struct unw_dynamic_unwind_sections *info);
// Returns UNW_ESUCCESS if successfully registered, UNW_EINVAL for duplicate
// registrations, and UNW_ENOMEM to indicate too many registrations.
extern int __unw_add_find_dynamic_unwind_sections(
unw_find_dynamic_unwind_sections find_dynamic_unwind_sections);
// Returns UNW_ESUCCESS if successfully deregistered, UNW_EINVAL to indicate
// no such registration.
extern int __unw_remove_find_dynamic_unwind_sections(
unw_find_dynamic_unwind_sections find_dynamic_unwind_sections);
```
These can be used to register and deregister callbacks that have a similar
signature to `_dyld_find_unwind_sections`. During unwinding if
`_dyld_find_unwind_sections` returns false (indicating that no frame info
was found by dyld) then registered callbacks are run in registration order until
either the unwind info is found or the end of the list is reached.
With this commit, and by implementing the find-unwind-info callback in the ORC
runtime in LLVM, we (1) enable support for registering JIT'd compact-unwind info
with libunwind*, (2) provide a way to identify the subarchitecture for each frame
(by returning a pointer to a JIT'd MachO header), and (3) delegate tracking of
unwind info to the callback, which may be able to implement more efficient
address-based lookup than libunwind.
* JITLink does not process or register compact unwind info yet, so this patch
does not fully enable compact unwind info in ORC, it simply provides some
necessary plumbing. JITLink support for compact unwind should land some time
in the LLVM 17 development cycle.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D142176
The repeated instructions make the file long and difficult to read.
Simplify them with .irp directives.
Skip PowerPC since AIX assembler doesn't support .irp
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D139368
This reverts commit 8482e95f75d02227fbf51527680c0b5424bacb69, which breaks on AIX
due to unsupported psudeo-ops in the assembly.
Differential Revision: https://reviews.llvm.org/D139368
The repeated instructions make the file long and difficult to read.
Simplify them with .irp directives.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D139368
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
