The CMake variable LIBUNWIND_SUPPORTS_NODEFAULTLIBS_FLAG has been renamed
into C_SUPPORTS_NODEFAULTLIBS_FLAG because the last one is used in the
confix-ix.cmake file while the variable with the original name is not used
at al.
Differential Revision: https://reviews.llvm.org/D126466
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
Create a macro for this instead of duplicating the architecture checks
everywhere. (It's a little redundant to use it when we're checking for a
specific architecture, but I'm also applying it there for consistency.)
Reviewed By: rprichard, MaskRay, #libunwind
Differential Revision: https://reviews.llvm.org/D126342
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
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)
Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library. If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.
The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.
(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)
This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.
Differential Revision: https://reviews.llvm.org/D125715
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
Reland: test moved because it depends on exceptions.
This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
Standalone builds have been deprecated and then removed for a while now.
Trying to use standalone builds leads to a fatal CMake error, so this
code is all dead. Remove it to clean things up.
Differential Revision: https://reviews.llvm.org/D125561
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
We add `--unwindlib=none` to `CMAKE_REQUIRED_FLAGS`
to make sure that builds with a yet-incomplete toolchain succeed,
to avoid linker failures about missing unwindlib.
When this option is added to `CMAKE_REQUIRED_FLAGS`, it gets added to
both compile and link commands in CMake compile tests. If
`--unwindlib=none` is included in compilation commands, it causes
warnings about unused arguments, as the flag only is relevant for
linking.
Due to the warnings in CMake tests, the later CMake test for the
`-Werror` option failed (as the tested `-Werror` option caused the
preexisting warning due to unused `--unwindlib=none` to become a
hard error). Therefore, most CI configurations that build with
`LIBCXX_ENABLE_WERROR` didn't actually end up enabling `-Werror`
after all.
When looking at the CI build log of recent CI builds, they do
end up printing:
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG - Failed
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG - Failed
Thus while the configurations are meant to error out on warnings,
they actually haven't done that, due to the interaction of these
options.
To fix this, remove the individual cases of adding `--unwindlib=none`
into `CMAKE_REQUIRED_FLAGS` in libcxx and libunwind.
`runtimes/CMakeLists.txt` still adds `--unwindlib=none` if needed, but
not otherwise. (The same issue with enabling `-Werror` does remain
if `--unwindlib=none` strictly is needed though - that can be fixed
separately afterwards.)
These individual cases in libunwind and libcxx were added while
standalone builds of the runtimes still were supported - but no longer
are necessary now.
Differential Revision: https://reviews.llvm.org/D124375
This makes sure to include libunwind log messages in the build if
LIBUNWIND_ENABLE_ASSERTIONS is set (which it is by default), when
building in RelWithDebInfo configurations.
Differential Revision: https://reviews.llvm.org/D124912
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
Add support for the SystemZ (s390x) architecture to libunwind.
Support should be feature-complete with the exception of
unwinding from signal handlers (to be added later).
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D124248
When the sigreturn trampoline is found the unw_proc_info_t.end_ip need to be set to
indicate a stack frame is found.
Reviewed By: cjdb, #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D124522
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
Summary:
This is an add-on patch to address comments.
- Replace #elif in file <assembly.h> with #else as suggested;
- Reversed the indentation changes in the main patch.
Differential Revision: https://reviews.llvm.org/D100132
Summary:
This patch contains the implementation of the unwinder for IBM AIX.
AIX does not support the eh_frame section. Instead, the traceback table located at the end of each function provides the information for stack unwinding and EH. In this patch macro _LIBUNWIND_SUPPORT_TBTAB_UNWIND is used to guard code for AIX traceback table based unwinding. Function getInfoFromTBTable() and stepWithTBTable() are added to get the EH information from the traceback table and to step up the stack respectively.
There are two kinds of LSDA information for EH on AIX, the state table and the range table. The state table is used by the previous version of the IBM XL compiler, i.e., xlC and xlclang++. The DWARF based range table is used by AIX clang++. The traceback table has flags to differentiate these cases. For the range table, relative addresses are calculated using a base of DW_EH_PE_datarel, which is the TOC base of the module where the function of the current frame belongs.
Two personality routines are employed to handle these two different LSDAs, __xlcxx_personality_v0() for the state table and __xlcxx_personality_v1() for the range table. Since the traceback table does not have the information of the personality for the state table approach, its personality __xlcxx_personality_v0() is dynamically resolved as the handler for the state table. For the range table, the locations of the LSDA and its associated personality routine are found in the traceback table.
Assembly code for 32- and 64-bit PowerPC in UnwindRegistersRestore.S and UnwindRegistersSave.S are modified so that it can be consumed by the GNU flavor assembler and the AIX assembler. The restoration of vector registers does not check VRSAVE on AIX because VRSAVE is not used in the AIX ABI.
Reviewed by: MaskRay, compnerd, cebowleratibm, sfertile, libunwind
Differential Revision: https://reviews.llvm.org/D100132
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
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
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
We should not assume that the cet.h header exists just because
we're on x86 linux. Only include it if __CET__ is defined. This
makes the code more similar to what compiler-rt does in
ee423d93ea/compiler-rt/lib/builtins/assembly.h (L17)
(though that one also has a __has_include() check -- I've not found
that to be necessary).
Differential Revision: https://reviews.llvm.org/D119697
We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.
Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.
Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.
Differential Revision: https://reviews.llvm.org/D119351
The warning was introduced with the recently merged SPARCv9
support in 2b9554b885.
The cast matches the existing surrounding cases.
Differential Revision: https://reviews.llvm.org/D119353
Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.
This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.
Differential Revision: https://reviews.llvm.org/D119255
Add SPARC to the list of platforms for which we provide a full
unwind implementation which leads to _Unwind_Backtrace being defined within
libunwind.so.
Likewise for PPC (see D118320 for background).
Reviewed By: #libunwind, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D119068
Adds libunwind support for SPARCv9 (aka sparc64). This is a rebase of @kettenis' patch D32450, which I created (with his permission) because the original review has become inactive.
The changes are of a cosmetic nature to make it fit better with the new code style, and to reuse the existing SPARCv8 code, whenever possible.
Please let me know if I posted this on the wrong place. Also, the summary of the original review is reproduced below:
> This adds unwinder support for 64-bit SPARC (aka SPARCv9). The implementation was done on OpenBSD/sparc64, so it takes StackGhost into account:
>
> https://www.usenix.org/legacy/publications/library/proceedings/sec01/full_papers/frantzen/frantzen_html/index.html
>
> Since StackGhost xor's return addresses with a random cookie before storing them on the stack, the unwinder has to do some extra work to recover those. This is done by introducing a new kRegisterInCFADecrypt "location" type that is used to implement the DW_CFA_GNU_window_save opcode. That implementation is SPARC-specific, but should work for 32-bit SPARC as well. DW_CFA_GNU_window_save is only ever generated on SPARC as far as I know.
Co-authored-by: Mark Kettenis
Reviewed By: #libunwind, thesamesam, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D116857
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
Pavel Samolysov