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
If you're building libunwind instrumented with ASan, `_Unwind_RaiseException`
will poison the stack and then transfer control in a manner which isn't
understood by ASan, so the stack will remain poisoned. This can cause
false positives, e.g. if you call an uninstrumented function (so it
doesn't re-poison the stack) after catching an exception. Add a call to
`__asan_handle_no_return` inside `__unw_resume` to get ASan to unpoison
the stack and avoid this.
`__unw_resume` seems like the appropriate place to make this call, since
it's used for resumption by all unwind implementations except SJLJ. SJLJ
uses `__builtin_longjmp` to handle resumption, which is already
recognized as noreturn (and therefore ASan adds the `__asan_handle_no_return`
call itself), so it doesn't need any special handling.
PR32434 is somewhat similar (in particular needing a component built
without ASan to trigger the bug), and rG781ef03e1012, the fix for that
bug, adds an interceptor for `_Unwind_RaiseException`. This interceptor
won't always be triggered though, e.g. if you statically link the
unwinder into libc++abi in a way that prevents interposing the unwinder
functions (e.g. marking the symbols as hidden, using `--exclude-libs`,
or using `-Bsymbolic`). rG53335d6d86d5 makes `__cxa_throw` call
`__asan_handle_no_return` explicitly, to similarly avoid relying on
interception.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D103002
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
Summary:
This NFC patch replaces the representation of registers and the left shift operator in the PowerPC assembly code to allow it to be consumed by the GNU flavored assembler and the AIX assembler.
* Registers - change the representation of PowperPC registers from %rn, %fn, %vsn, and %vrn to the register number alone, e.g., n. The GNU flavored assembler and the AIX assembler are able to determine the register kind based on the context of the instruction in which the register is used.
* Left shift operator - use macro PPC_LEFT_SHIFT to represent the left shift operator. The left shift operator in the AIX assembly language is < instead of <<
Reviewed by: sfertile, MaskRay, compnerd
Differential Revision: https://reviews.llvm.org/D101179
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.
Differential Revision: https://reviews.llvm.org/D100869
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
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
immediate build failure when Cross Unwinding enabled.
Follow up patch will cleanup some Macros handling.
Differential Revision: https://reviews.llvm.org/D97762
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
Rename the CMake option, LIBUNWIND_HERMETIC_STATIC_LIBRARY, to
LIBUNWIND_HIDE_SYMBOLS. Rename the C macro define,
_LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS, to _LIBUNWIND_HIDE_SYMBOLS,
because now the macro adds a .hidden directive rather than merely
suppress visibility annotations.
For ELF, when LIBUNWIND_HIDE_SYMBOLS is enabled, mark unw_getcontext as
hidden. This symbol is the only one defined using src/assembly.h's
WEAK_ALIAS macro. Other unw_* weak aliases are defined in C++ and are
already hidden.
Mach-O doesn't support weak aliases, so remove .weak_reference and
weak_import. When LIBUNWIND_HIDE_SYMBOLS is enabled, output
.private_extern for the unw_* aliases.
In assembly.h, add missing SYMBOL_NAME macro invocations, which are
used to prefix symbol names with '_' on some targets.
Fixes PR46709.
Reviewed By: #libunwind, phosek, compnerd, steven_wu
Differential Revision: https://reviews.llvm.org/D93003
This change adds support for the dwarf PC register column in arm64, allowing
CFI directives to make use of it.
As of the last revision of the DWARF for ARM 64-bit architecture[0], the pc
register has been added as a valir register, with number 32.
This allows libunwinder to restore both pc and lr, which is useful
for stack switches and signal contexts.
[0]:
f52e1ad3f8/aadwarf64/aadwarf64.rst
Reviewed By: phosek, #libunwind
Differential Revision: https://reviews.llvm.org/D96901
Null return addresses can appear at the bottom of the stack (i.e. the
frame corresponding to the entry point). Authenticating these addresses
will set the error code in the address, which will lead to a segfault
in the sigreturn trampoline detection code. Fix this problem by not
authenticating null addresses.
Differential Revision: https://reviews.llvm.org/D96560
Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before.
This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out.
The propose change will allow to make the link step simple for other platforms as well.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D95875
An error has occurred when I build libunwind with -DLLVM_BUILD_DOCS=ON.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D96107
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
Modify libunwind to support SjLj exception handling routines for VE.
In order to do that, we need to implement not only SjLj exception
handling routines but also a Registers_ve class. This implementation
of Registers_ve is incomplete. We will work on it later when we need
backtrace in libunwind.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D94591
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
* Remove misnamed `PPC64_HAS_VMX` in preference of directly checking `defined(__VSX__)`.
libunwind was using "VMX" to mean "VSX". "VMX" is just another name for Altivec, while "VSX" is the vector-scalar extensions first used in POWER7. Exposing a "PPC64_HAS_VMX" define was misleading and incorrect.
* Add `defined(__ALTIVEC__)` guards around vector register operations to fix non-altivec CPUS such as the e5500.
When compiling for certain Book-E processors such as the e5500, we want to skip vector save/restore, as the Altivec registers are illegal on non-Altivec implementations.
* Add `!defined(__NO_FPRS__)` guards around traditional floating-point save/restore.
When compiling for powerpcspe, we cannot access floating point registers, as there aren't any. (The SPE on e500v2 is a 64-bit extension of the GPRs, and it doesn't have the normal floating-point registers at all.)
This fixes building for powerpcspe, although no actual handling for SPE save/restore is written yet.
Reviewed By: MaskRay, #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D91906
When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).
llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.
This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.
This is a revert of the following commits:
libunwind: 3a667b9bd8
libc++abi: 4877063e19
libc++: 88434fe05f
Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.
Differential Revision: https://reviews.llvm.org/D91099
ld64 uses them to create compact unwind from DWARF call frame information.
When the code was ported to libunwind, the variables were not deleted.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D91039
Summary:
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.
This patch just reorganises the code to make possible to use alloca
instead of malloc. This makes possible to use `.cfi_remember_state`/`.cfi_restore_state` on
platforms without heap allocation.
Also it will be safe to backtrace/unwind faults related to the allocator behind malloc.
`_LIBUNWIND_REMEMBER_HEAP_ALLOC ` option reenables the heap usage for `.cfi_remember_state`/`.cfi_restore_state`.
Define _LIBUNWIND_REMEMBER_STACK_ALLOC to force stack allocation.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D85005
--export-dynamic is not always available on all targets.
-funwind-tables was a duplicate in the lit.site.cfg.in.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D90202
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
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.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
This unfortunately means that we don't execute C++ destructors when
unwinding past such frames for a different SEH unwind purpose (e.g.
as part of setjmp/longjmp), but that case isn't handled properly at
the moment (the original unwind intent is lost and we end up with an
unhandled exception). This patch makes sure the foreign unwind terminates
as intended.
After executing a handler, _Unwind_Resume doesn't have access to
the target frame parameter of the original foreign unwind. We also
currently blindly set ExceptionCode to STATUS_GCC_THROW - we could
set that correctly by storing the original code in _GCC_specific_handler,
but we don't have access to the original target frame value.
This also matches what libgcc's SEH unwinding code does in this case.
Differential Revision: https://reviews.llvm.org/D89231
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
The .note.gnu.property must be in the assembly file to indicate the
support for BTI otherwise BTI will be disabled for the whole library.
__unw_getcontext and libunwind::Registers_arm64::jumpto() may be called
indirectly therefore they should start with a landing pad.
Reviewed By: tamas.petz, #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D77786
Currently, findUnwindSectionsByPhdr is slightly micro-optimized for the
case where the first callback has the target address, and is otherwise
very inefficient -- it decodes .eh_frame_hdr even when no PT_LOAD
matches the PC. (If the FrameHeaderCache is enabled, then the
micro-optimization only helps the first time unwind info is looked up.)
Instead, it makes more sense to optimize for the case where the
callback *doesn't* find the target address, so search for a PT_LOAD
segment first, and only look for the unwind info section if a matching
PT_LOAD is found.
This change helps on an Android benchmark with 100 shared objects,
where the DSO at the end of the dl_iterate_phdr list throws 10000
exceptions. Assuming the frame cache is disabled, this change cuts
about 30-40% off the benchmark's runtime.
Reviewed By: compnerd, saugustine, #libunwind
Differential Revision: https://reviews.llvm.org/D87881
dl_iterate_phdr is used to search for unwind info provided by either
PT_GNU_EH_FRAME or PT_ARM_EXIDX. Most of the code between the two is
the same, so combine them, and factor out what's different into
checkForUnwindInfoSegment.
Details:
- The FrameHeaderCache can now be enabled for ARM EHABI.
- findUnwindSectionsByPhdr now finds the last PT_ARM_EXIDX rather than
the first. There should only be one segment.
- The dso_base and text_segment_length fields of UnwindInfoSections
are now needed for dl_iterate_phdr when using EHABI, to hold the
low and high PC values for a cache entry.
Reviewed By: compnerd, danielkiss, #libunwind, saugustine
Differential Revision: https://reviews.llvm.org/D87880
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
Unwinding leaf function is useful in cases when the backtrace finds a
leaf function for example when it caused a signal.
This patch also add the support for the DW_CFA_undefined because it marks
the end of the frames.
Ryan Prichard provided code for the tests.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D83573
Reland with limit the test to the x86_64-linux target.
* When .eh_frame is located using .eh_frame_hdr (PT_GNU_EH_FRAME), the
start of .eh_frame is known, but not the size. In this case, the
unwinder must rely on a terminator present at the end of .eh_frame.
Set dwarf_section_length to UINTPTR_MAX to indicate this.
* Add a new field, text_segment_length, that the FrameHeaderCache uses
to track the size of the PT_LOAD segment indicated by dso_base.
* Compute ehSectionEnd by adding sectionLength to ehSectionStart,
never to fdeHint.
Fixes PR46829.
Differential Revision: https://reviews.llvm.org/D87750
Unwinding leaf function is useful in cases when the backtrace finds a
leaf function for example when it caused a signal.
This patch also add the support for the DW_CFA_undefined because it marks
the end of the frames.
Ryan Prichard provided code for the tests.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D83573
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
Previously, DwarfFDECache::findFDE used 0 as a special value meaning
"search the entire cache, including dynamically-registered FDEs".
Switch this special value to -1, which doesn't make sense as a DSO
base.
Fixes PR47335.
Reviewed By: compnerd, #libunwind
Differential Revision: https://reviews.llvm.org/D86748
Define a _LIBUNWIND_USE_DL_ITERATE_PHDR macro in config.h when there is
no other unwind info lookup method. Also define a
_LIBUNWIND_USE_DL_UNWIND_FIND_EXIDX macro to factor out
(__BIONIC__ and _LIBUNWIND_ARM_EHABI).
Differential Revision: https://reviews.llvm.org/D86768
Simplify:
defined(__ARM_DWARF_EH__) || !defined(__arm__)
to:
!defined(_LIBUNWIND_ARM_EHABI)
A later patch benefits from the simplicity. This change will result in
the two DWARF macros being defined when __USING_SJLJ_EXCEPTIONS__ is
defined, but:
* That's already the case with the __APPLE__ and _WIN32 clauses.
* That's also already the case with other architectures.
* With __USING_SJLJ_EXCEPTIONS__, most of the unwinder is #ifdef'ed
away.
Generally, when __USING_SJLJ_EXCEPTIONS__ is defined, most of the
libunwind code is removed by the preprocessor. e.g. None of the hpp
files are included, and almost all of the .c and .cpp files are defined
away, except in Unwind-sjlj.c. Unwind_AppleExtras.cpp is an exception
because it includes two hpp files, which it doesn't use. Remove the
unneeded includes for consistency with the general rule.
Reviewed By: steven_wu
Differential Revision: https://reviews.llvm.org/D86767
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Simply don't mark the file as C and CMake will recognize the rest.
This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple.
Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09.
Afterwards workarounds were added for MinGW and Apple:
* https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
* https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb
The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other.
The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287).
Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Example error:
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D86308
* When _LIBUNWIND_SUPPORT_COMPACT_UNWIND is defined in config.h,
define it to "1" like the other macros. These macros are still
checked using "#if defined(...)", however.
* Include libunwind.h in AddressSpace.hpp before using
_LIBUNWIND_ARM_EHABI.
* Rename ProcessFrameHeaderCache to TheFrameHeaderCache, because some
configurations (e.g. Android / hermetic static libraries) can have
one cache per shared object in the process. (When there are more
copies, it's more important not to waste memory in the cache.)
* Add 3 missing header files to LIBUNWIND_HEADERS.
Differential Revision: https://reviews.llvm.org/D86254
Currently, the assembly functions for restoring register state have
been direct implementations of the Registers_*::jumpto() method
(contrary to the functions for saving register state, which are
implementations of the extern C function __unw_getcontext). This has
included having the assembly function name match the C++ mangling of
that method name (and having the function match the C++ member
function calling convention). To simplify the interface of the assembly
implementations, make the functions have C calling conventions and
name mangling.
This fixes building the library in with a MSVC C++ ABI with clang-cl,
which uses a significantly different method name mangling scheme.
(The library might not be of much use as C++ exception unwinder in such
an environment, but the libunwind.h interface for stepwise unwinding
still is usable, as is the _Unwind_Backtrace function.)
Differential Revision: https://reviews.llvm.org/D86041
The static_assert macro broke on GCC when a scope had two asserts and a
condition that depended on a template parameter. Remove the macro and
rely on the compiler's C++11 static_assert feature.
The __has_feature macro was only used here to determine whether to
define the static_assert macro.
Reviewed By: mstorsjo, #libunwind
Differential Revision: https://reviews.llvm.org/D86411
Currently, this function is present in the dynsym table of
libunwind.so (on ELF targets). Make the function static instead.
In the previous release (LLVM 10.x), this function was instead a lambda
function inside LocalAddressSpace::findUnwindSections, and because
LocalAddressSpace was marked with _LIBUNWIND_HIDDEN, the lambda
function was also a hidden symbol.
Differential Revision: https://reviews.llvm.org/D86372
When built in SEH mode, UnwindCursor contains a CONTEXT struct,
which is aligned to 16 bytes in most configurations, causing the
whole UnwindCursor object to have 16 byte alignment.
This fixes backtraces using _Unwind_Backtrace on x86_64 mingw,
where an unw_cursor_t allocated on the stack was misaligned before.
This is an ABI break for this struct for this configuration, but very
few callers call libunwind directly (and even fewer directly allocate
an unw_cursor_t anyway).
Differential Revision: https://reviews.llvm.org/D86102
Although it works fine with glibc, as currently implemented the
frameheader cache is incompatible with certain platforms with
slightly different locking semantics inside dl_iterate_phdr.
Therefore only enable it when it is turned on explicitly with
a configure-time option.
Differential Revision: https://reviews.llvm.org/D86163
Remove `_dyld_find_unwind_sections` implementation for macOS that is
10.6 or previous. 10.6 is no longer supported for TOT libunwind after
removing its libkeymgr dependency.
Reviewed By: mstorsjo, pete, #libunwind
Differential Revision: https://reviews.llvm.org/D86104
Before this patch the `ninja check-unwind` won't rebuild the unwind library.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D85004
Set -Wno-suggest-override where such warning is provided
by the compiler when building libunwind, alongside libcxx
and libcxxabi, using recent Clang. This extends behavior
introduced in 77e0e9e17d
to libunwind, avoiding a large amount of warnings during
builds. See D84126 for the original patch.
Libunwind uses _LIBUNWIND_IS_BAREMETAL in a lot of places but there is no cmake variable to set it. This patch adds such a variable. It is quite like what LIBCXXABI_BAREMETAL does in libcxxabi.
Reviewed By: compnerd, #libunwind
Differential Revision: https://reviews.llvm.org/D84759
keymgr used to be used on MacOSX <= 10.6, however we don't build libunwind
from scratch for such old systems anymore. Hence, this code isn't useful
anymore.
Differential Revision: https://reviews.llvm.org/D84677
Previously, for large-enough values, getSLEB128 would attempt to shift
a signed int in the range [0..0x7f] by 28, 35, 42... bits, which is
undefined behavior and likely to fail.
Avoid shifting (-1ULL) by 70 for large values. e.g. For INT64_MAX, the
last two bytes will be:
- 0x7f [bit==56]
- 0x00 [bit==63]
Differential Revision: https://reviews.llvm.org/D83742
- For CIE version 1 (e.g. in DWARF 2.0.0), the return_address_register
field is a ubyte [0..255].
- For CIE version 3 (e.g. in DWARF 3), the field is instead a ULEB128
constant.
Previously, libunwind accepted a CIE version of 1 or 3, but always
parsed the field as ULEB128.
Clang always outputs CIE version 1 into .eh_frame. (It can output CIE
version 3 or 4, but only into .debug_frame.)
Differential Revision: https://reviews.llvm.org/D83741
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
Add missing `operator!=` and make `operator-` const for
`EHABISectionIterator`. This repairs the build of libunwind when
building with GCC.
Patch by Chad Duffin!
Reviewed By: compnerd, libunwind
Differential Revision: https://reviews.llvm.org/D81597
Summary:
This allows unwinding to work across signal handler frames where the IP of the previous frame is not the same as the current value of the RA register. This is particularly useful for acquiring backtraces from signal handlers.
I kept the size of the context structure the same to avoid ABI breakage; the PC is stored in the previously unused slot for register 0.
Reviewers: #libunwind, mhorne, lenary, luismarques, arichardson, compnerd
Reviewed By: #libunwind, mhorne, lenary, compnerd
Subscribers: kamleshbhalui, jrtc27, bsdjhb, arichardson, compnerd, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, psnobl, benna, Jim, s.egerton, sameer.abuasal, evandro, llvm-commits, libcxx-commits
Tags: #libunwind, #llvm
Differential Revision: https://reviews.llvm.org/D78931
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.
This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.
Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
The ARM specific code was trying to determine endianness using the
`__LITTLE_ENDIAN__` macro which is not guaranteed to be defined.
When not defined, it makes libunwind to build the big-endian code even
when the compiler builds for a little-endian target.
This change allows building libunwind with the `musl-gcc` toolchain
which does not define `__LITTLE_ENDIAN__`. Use `__BYTE_ORDER__`
instead.
Patch by Idan Freiberg!
Add a missing guard for `_LIBUNWIND_NO_HEAP` around code dealing with the
`.cfi_remember_state` and `.cfi_restore_state` instructions.
Patch by Amanieu d'Antras!
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ and libc++abi tests. This commit
changes the libunwind tests to use the new format by default too. If
unexpected failures are discovered, it should be fine to revert this
commit until they are addressed.
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
Differential Revision: https://reviews.llvm.org/D77733
`__aarch64__` is defined for the target (since the beginning of arm64 support: clang 3.5).
`__arm64__` is only defined for the Darwin OS on AArch64.
`defined(__aarch64__) || defined(__arm64__)` can be simplied as `defined(__aarch64__)`
Darwin AArch64 uses %% as the assembly separator (see AArch64MCAsmInfo.cpp).
Make the intention explicit in src/assembly.h
With this change, the libunwind code base has no reference of `__arm64__`/`__arm64`.
Reviewed By: #libunwind, ldionne, mstorsjo
Differential Revision: https://reviews.llvm.org/D77829
The LIT substitutions used in libunwind are the same as those from
libc++, and we forgot to update the libunwind tests after the libc++
substitutions started being delimited by braces.
When the EHHeaderInfo object filled by decodeEHHdr has fde_count == 0,
findFDE does the following:
- sets low = 0 and len = hdrInfo.fde_count as a preparation to start a
binary search
- because len is 0, the binary search loop is skipped
- the code still tries to find a table entry at
hdrInfo.table + low * tableEntrySize, and decode it.
This is wrong when fde_count is 0, and trying to decode a table entry
that isn't there will lead to reading garbage offsets and can cause
segfaults.
Differential Revision: https://reviews.llvm.org/D77679
Summary:
This patch follows libgcc's lead: When the return-address register is
zero, there won't be additional stack frames to examine, or gather
information about. Exit before spending time looking for something
known not to be found.
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77099
Summary:
This improves unwind performance quite substantially, and follows
a somewhat similar approach used in libgcc_s as described in the
thread here:
https://gcc.gnu.org/ml/gcc/2005-02/msg00625.html
On certain extremely exception heavy internal tests, the time
drops from about 80 minutes to about five minutes.
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75954
Summary:
Copying all of the saved register state on every entry to
parseInstruction is a severe performance contraint, especially
because most of this saved state is never used. On x86 linux
this is about 560 bytes, and will be more on other platforms.
When performance testing libunwind, this memcpy appears at the
top of nearly all our tests.
By only saving this state as needed, we see increasing in performance
of around 2.5% for the ctak test here.
https://github.com/clasp-developers/ctak
Certain internal extremely exception-heavy tasks run in about 2/3
the time.
Note that by stashing the new boolean inside what had been padding in
the original structure, this uses no additional memory.
Subscribers: fedor.sergeev, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75692
We were seeing non-deterministic binary size differences depending on which
toolchain was used to build fuchsia. This is because libunwind embeded the
FILE path into a logging macro, even for release builds, which makes the code
dependent on the build directory.
This removes the file and line number from the error message. This is
consistent with how other runtimes report error, e.g.
https://github.com/llvm/llvm-project/blob/master/libcxxabi/src/abort_message.cpp#L30.
Differential Revision: https://reviews.llvm.org/D75890
Summary:
- Executable segment is usually segment 3. Look there for the address first.
- GNU_EH_FRAME_HEADER segment is usually near the end. Iterate from the end.
- Exit early if both phdrs have been found.
This is the last cl before a patch to cache the information this function
finds.
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75781
Summary:
This further cleans up the control flow and makes it easier to
optimize and replace portions in a subsequent patch.
This should be NFC, but given the amount of #ifdeffing here,
it may not be. So will watch the buildbots closely.
Also, as this is purely moving existing code around, I plan to
ignore the lint errors.
Reviewers: compnerd, miyuki, mstorsjo
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75705
Summary:
This cleans up control flow inside findUnwindSections, and will make
it easier to replace this code in a following patch. Also, expose the
data structure to allow use by a future replacment function.
Reviewers: mstorsjo, miyuki
Subscribers: krytarowski, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75637
This reverts commit d93371238e.
The commit broke the build in several configurations (including
Windows and bare-metal). For details see comments in
https://reviews.llvm.org/D75480
to allow use by a future replacment function.
Summary: [Refactor] Promote nameless lambda to fully named function, allowing easy replacement in following patch.
Subscribers: krytarowski, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75480
The OSX_ARCHITECTURES property is supposed to add the -arch flag when
targeting Apple platforms. However, due to a bug in CMake
(https://github.com/Kitware/CMake/blob/master/Source/cmLocalGenerator.cxx#L1780),
this does not apply to assembly files. This results in a linker error
when trying to build libunwind for i386 on MacOS.
rdar://59642189
parseInstructions() doesn't always process the whole set of DWARF
instructions for a frame. It will stop once the target PC is reached, or
if malformed instructions are found. So, for example, if we have an
instruction sequence like this:
```
<start>
...
DW_CFA_remember_state
...
DW_CFA_advance_loc past the location we're unwinding at (pcoffset in parseInstructions() main loop)
...
DW_CFA_restore_state
<end>
```
... the saved state will never be freed, even though the
DW_CFA_remember_state opcode has a matching DW_CFA_restore_state later
in the sequence.
This change adds code to free whatever is left on rememberStack after
parsing the CIE and the FDE instructions.
Differential Revision: https://reviews.llvm.org/D66904
This patch renames `__personality_routine` to `_Unwind_Personality_Fn`
in `unwind.h`. Both `unwind.h` from clang and GCC headers use this name
instead of `__personality_routine`. With this patch one is also able to
build libc++abi with libunwind support on Windows.
Patch by Markus Böck!
```
src/UnwindCursor.hpp:1344:51: error: operator '?:' has lower precedence than '|';
'|' will be evaluated first [-Werror,-Wbitwise-conditional-parentheses]
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
~~~~~~~~~~~ ^
src/UnwindCursor.hpp:1344:51: note: place parentheses around the '|' expression
to silence this warning
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
^
( )
src/UnwindCursor.hpp:1344:51: note: place parentheses around the '?:' expression
to evaluate it first
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
^
( )
```
But `0 |` is a no-op for either of those two interpretations, so I think
what was meant here was
```
_info.flags = (isSingleWordEHT ? 1 : 0) | (scope32 ? 0x2 : 0); // Use enum?
```
Previously, if `isSingleWordEHT` was set, bit 2 would never be set. Now
it is. From what I can tell, the only thing that checks these bitmask is
ProcessDescriptors in Unwind-EHABI.cpp, and that only cares about bit 1,
so in practice this shouldn't have much of an effect.
Differential Revision: https://reviews.llvm.org/D73890
When targeting mingw, current CMake (3.16) fails to get the right
flags for assembly source files for windows gnu/clang targets
(see https://gitlab.kitware.com/cmake/cmake/merge_requests/4287
for a fix), causing builds to fail due to `-fPIC` being unsupported
in clang for mingw targets
In the meantime, restore the behaviour from before c48974ffd7
selectively on mingw targets, treating the assembly files as C.
Differential Revision: https://reviews.llvm.org/D73436
After this change, we need to explicitly list the languages the
project uses, otherwise the assembly source files won't get built
at all.
Previously (before that commit), the assembly source files were
simply treated as C.
The toplevel llvm CMakeLists.txt adds these three languages, so
when building libunwind integrated as part of that, it works fine.
I believe this is an oversight from the import of libunwind into its own
library from libc++abi.
In libc++abi, these files had the .s suffix, which indicates that the file
is a preprocessed assembly source file. This caused problems because the
files rely upon preprocessors to guard target-specific blocks.
To fix this, the CMakeLists file marked these files as C so that the
preprocessor would be run over them, but then the compiler would correctly
identify the files as assembly and compile them as such.
When imported to libunwind, these files were (correctly) renamed with .S
suffixes, which are non-preprocessed assembly. Thus, we no longer need the
C language property.
The benefit here is that the files can now benefit from CMAKE_ASM_FLAGS
rather than CMAKE_C_FLAGS.
Patch By: JamesNagurne
Differential Revision: https://reviews.llvm.org/D72952
reg is unsigned type and used here for getting array element from the end by
negating it. negation of unsigned can result in large number and array access
with that index will result in segmentation fault.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=43872
Patched by: kamlesh kumar
Differential Revision: https://reviews.llvm.org/D69893
Summary:
Add unwinding support for 64-bit RISC-V.
This is from the FreeBSD implementation with the following minor
changes:
- Renamed and renumbered DWARF registers to match the RISC-V ABI [1]
- Use the ABI mneumonics in getRegisterName() instead of the exact
register names
- Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit
ABI in the future.
[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
Patch by Mitchell Horne (mhorne)
Reviewers: lenary, luismarques, compnerd, phosek
Reviewed By: lenary, luismarques
Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski, simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl, benna, lenary, s.egerton, luismarques, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D68362
Summary:
Relands https://reviews.llvm.org/D70815.
The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to
`STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively
disabled the linking step in CMake checks.
This broke some builds (see 938c70b86c).
Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to
STATIC_LIBRARY only when checking for presence of the `-funwind-tables`
flag, and then set it back to the original value so it doesn't affect
other checks.
Reviewers: mstorsjo, jfb
Subscribers: mgorny, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71117
This reverts commit b3fdf33ba6.
This change broke building libunwind for Windows/MinGW, and broke
on aspect of the CMake tests in libunwind in general.
After set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), CMake
skips the linking step in tests, but cmake/config-ix.cmake also
does a few checks for functions in libraries (looking for whether
-lc provides fopen and whether -ldl provides dladdr).
As CMake only tests building a static library, these tests
incorrectly succeed and CMake concludes "Looking for fopen in c -
found" and "Looking for dladdr in dl - found", while building
then fails at the end with errors about unable to find -lc and -ldl.
Summary:
Or, rather, don't accidentally forget to pass it.
This is aimed to solve the problem discussed in [this thread](http://lists.llvm.org/pipermail/llvm-dev/2019-November/136890.html), and to fix [a year-old bug](https://bugs.llvm.org/show_bug.cgi?id=38468).
TL;DR: when building libunwind for ARM Linux, we **need** libunwind to be built with the `-funwind-tables` flag, because, well ARM EHABI needs unwind info produced by this flag. Without the flag all the procedures in libunwind are marked `.cantunwind`, which causes all sorts of bad things. From `_Unwind_Backtrace` not working, to C++ exceptions not being caught (which is the aforementioned bug is about).
Previously, this flag was not added because the CMake check `add_compile_flags_if_supported(-funwind-tables)` produced a false negative. Why? With this flag, the compiler generates calls to the `__aeabi_unwind_cpp_pr0` symbol, which is defined in libunwind itself and obviously is not available at configure time, before libunwind is built. This led to failure at link time during the CMake check. We handle this by disabling the linker for CMake checks in linbunwind.
Also, this patch introduces a lit feature `libunwind-arm-ehabi`, which is used to mark the `signal_frame.pass.cpp` test as unsupported (as was advised by @miyuki in D70397).
Reviewers: peter.smith, phosek, EricWF, compnerd, jroelofs, saugustine, miyuki, jfb
Subscribers: mgorny, kristof.beyls, christof, libcxx-commits, miyuki
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70815
996e62eef7 added Linux-specific dependent libraries to libunwind
sources. As a result, building libunwind with modern LLD on *BSD
started failing due to trying to link libdl. Instead, add those
libraries only if they were detected by CMake.
While technically we could create a long list of systems that need -ldl
and -lpthread, maintaining a duplicate list makes little sense when
CMake needs to detect it for non-LLD systems anyway. Remove existing
system exceptions since they should be covered by the CMake check
anyway.
Remove -D_LIBUNWIND_HAS_COMMENT_LIB_PRAGMA since it is no longer
explicitly needed, if we make the library-specific defines dependent
on presence of this pragma support.
Differential Revision: https://reviews.llvm.org/D70868
Summary:
This patch adjusts the signal_frame.pass.cpp to pass on Arm targets:
* When Arm EHABI is used the unwinder does not use DWARF, hence the
DWARF-specific check unw_is_signal_frame() must be disabled.
* Certain C libraries don't include EH tables, so the unwinder must
not try to step out of main(). The patch moves the test code out of
main() into a separate function to avoid this.
Reviewers: saugustine, ostannard, phosek, jfb, mclow.lists
Reviewed By: saugustine
Subscribers: dexonsmith, aprantl, kristof.beyls, christof, libcxx-commits, pbarrio, labrinea
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70397
A "signal frame" is a function or block of code where execution arrives via a signal or interrupt, rather than via a normal call instruction. In fact, a particular instruction is interrupted by the signal and needs to be restarted. Therefore, when the signal handler is complete, execution needs to return to the interrupted instruction, rather than the instruction immediately following the call instruction, as in a normal call.
Stack unwinders need to know this to correctly unwind signal frames. Dwarf handily provides an "S" in the CIE augmentation string to describe this case, and the libunwind API provides various functions to for unwinders to determine it,.
The llvm libunwind implementation correctly sets it's internal variable "isSignalFrame" when initializing an unwind context. However, upon stepping up the stack, the current implementation correctly reads the augmentation string and sets it in the CIE info (which it then discards), libunwind doesn't update it's internal unwind context data structure.
This change fixes that, and provides compatibility with both the canonical libunwind and the libgcc implementation.
Reviewers: jfb
Subscribers: christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69677
Have CMake treat the unwind libraries as C libraries rather than C++.
There is no C++ runtime dependency at runtime. This ensures that we do
not accidentally end up with a link against the C++ runtime.
We need to explicitly reset the implicitly linked libraries for C++ to
ensure that we do not have CMake force the link against the C++ runtime.
This adjustment should enable the NetBSD bots to be happy with this
change.
gejin