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
Defines enums for the LoongArch registers.
Adds the register class implementation for LoongArch.
Adds save and restore context functionality.
This only supports 64 bits integer and float-point register
implementation.
Fix https://github.com/llvm/llvm-project/issues/55398
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137010
If CET shadow stack is enabled, we count the number of stack frames skipped
and adjust CET shadow stack based on the number in libunwind unwind_phase2.
At the same time, we can enhance security via comparing the return address in
normal stack against counterpart in CET shadow stack, if they don't match,
it means the return address stored in normal stack has been corrupted and we
will return _URC_FATAL_PHASE2_ERROR in that case.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136667
Signed-off-by: jinge90 <ge.jin@intel.com>
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
Add module maps for the libunwind headers. unwind_arm_ehabi.h and unwind_itanium.h aren't covered because they don't get installed on all platforms.
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D135345
However, mark them as EXCLUDE_FROM_ALL when we don't want to build them.
Simply declaring the targets should be of no harm, and it allows other
projects to mention these targets regardless of whether they end up
being built or not.
While the diff may not make that obvious, this patch basically
moves the definition of e.g. `cxx_shared` out of the `if (LIBCXX_ENABLE_SHARED)`
and instead marks it as `EXCLUDE_FROM_ALL` conditionally on whether
LIBCXX_ENABLE_SHARED is passed. It then does the same for libunwind
and libc++abi targets.
Differential Revision: https://reviews.llvm.org/D134221
We already had the ability to do that for libc++.dylib, so this only adds
consistency for all the runtime libraries. This should allow working around
difficulties on AIX as described in https://llvm.org/D134221.
Differential Revision: https://reviews.llvm.org/D135669
Just like we install libc++ and libc++abi headers by default when we
install the library, it makes sense to install the libunwind headers
by default when we build libunwind. In the current state of things,
there is an increased risk that folks are using older (previously
installed) libunwind headers along with a recent libunwind dylib,
which is not ideal.
Differential Revision: https://reviews.llvm.org/D135663
Now that all jobs have moved over to the new style of Lit configuration,
we can remove all traces of the legacy testing configuration system.
This includes:
- Cache settings that are not honored or useful anymore
- Several CMake options that were only useful in the context of the
legacy Lit configuration system
- A bunch of Python support code that is not used anymore
- The legacy lit.cfg.in files themselves
Differential Revision: https://reviews.llvm.org/D134650
Tested with the following program:
```
static volatile int* x = nullptr;
void throws() __attribute__((noinline)) {
if (getpid() == 0)
return;
throw "error";
}
void maybe_throws() __attribute__((noinline)) {
volatile int y = 1;
x = &y;
throws();
y = 2;
}
int main(int argc, char** argv) {
int y;
try {
maybe_throws();
} catch (const char* e) {
//printf("Caught\n");
}
y = *x;
printf("%d\n", y); // should be MTE failure.
return 0;
}
```
Built using `clang++ -c -O2 -target aarch64-linux -fexceptions -march=armv8-a+memtag -fsanitize=memtag-heap,memtag-stack`
Currently only Android implements runtime support for MTE stack tagging.
Without this change, we crash on `__cxa_get_globals` when trying to catch
the exception (because the stack frame __cxa_get_globals frame will fail due
to tags left behind on the stack). With this change, we crash on the `y = *x;`
as expected, because the stack frame has been untagged, but the pointer hasn't.
Reviewed By: #libunwind, compnerd, MaskRay
Differential Revision: https://reviews.llvm.org/D128998
On 32-bit x86, `_dl_find_object` also returns a `dlfo_eh_dbase` address.
So far, compiling against a version of `_dl_find_object` which returns a
`dlfo_eh_dbase` was blocked using a `#if` + `#error`. This commit now
removes this compile time assertion and simply ignores the returned
`dlfo_eh_dbase`. All test cases are passing on a 32-bit build now.
According to https://www.gnu.org/software/libc/manual/html_node/Dynamic-Linker-Introspection.html,
`dlfo_eh_dbase` should be the base address for all DW_EH_PE_datarel
relocations. However, glibc/elf/dl-find_object.h says that eh_dbase
is the relocated DT_PLTGOT value. I don't understand how those two
statements fit together, but to fix 32-bit x86, ignoring `dlfo_eh_dbase`
seems to be good enough.
Fixes#57733
Differential Revision: https://reviews.llvm.org/D133846
In UnwindCursor.hpp, include config.h before checking _LIBUNWIND_SUPPORT_SEH_UNWIND.
Include libunwind_ext.h for UNW_STEP_SUCCESS.
Differential Revision: https://reviews.llvm.org/D86766
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D130948
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Done according to @phosek's comments in D117537, but not done then to
separate pure refactor (that) from possible behavior change (this).
Wasn't working before, but I think that was due to an issue of mismatched variable names fixed in D110005.
Reviewed By: phosek, #libunwind, #libc_abi
Differential Revision: https://reviews.llvm.org/D117833
Summary:
The implementation of _Unwind_FindEnclosingFunction(void *ip) takes the context of itself and then uses the context to get the info of the function enclosing ip. This approach does not work for AIX because on AIX, the TOC base in GPR2 is used as the base for calculating relative addresses. Since _Unwind_FindEnclosingFunction() may be in a different shared lib than the function containing ip, their TOC bases can be different. Therefore, using the value of GPR2 in the context from _Unwind_FindEnclosingFunction() as the base results in incorrect addresses. On the other hand, the start address of a function is available in the traceback table following the instructions of each function on AIX. To get to the traceback table, search a word of 0 starting from ip and the traceback table is located after the word 0. This patch implements _Unwind_FindEnclosingFunction() for AIX by obtaining the function start address from its traceback table.
Reviewed by: compnerd, MaskRay, libunwind
Differential Revision: https://reviews.llvm.org/D131709
Summary:
libunwind on AIX calls dlopen()/dlsym()/dlclose() to dynamically load libc++abi and get the personality for state table EH when it is running against the legacy xlcang++ compiler genereated applications. dlopen() sets errno to 0 when it is successful, which clobbers the value in errno from the user code. This seems to be an AIX bug that it should not set errno to 0 according to POSIX. We will open a bug report to AIX but in the mean time there won't be time line when AIX will have a fix and even AIX does fix it, it won't help earlier AIX releases in the field. This patch saves and restores errno before and after these calls so that user code can work as expected.
Reviewed by: compnerd, libunwind
Differential Revision: https://reviews.llvm.org/D131292
This makes sure the assertions also get verified in optimized builds.
This matches what is already done in bad_unwind_info.pass.cpp.
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D131210
It must have been a copy-paste error, since cxx-include is never defined
by the libunwind config.
Differential Revision: https://reviews.llvm.org/D131030
According to EHABI32 §8.5.2, the PAC for the return address of a
function described in an exception table is supposed to be addressed
in the _Unwind_VRS_{Get,Set} API by setting regclass=_UVRSC_PSEUDO and
regno=0. (The space of 'regno' values is independent for each
regclass, and for _UVRSC_PSEUDO, there is only one valid regno so far.)
That is indeed what libunwind's _Unwind_VRS_{Get,Set} functions expect
to receive. But at two call sites, the wrong values are passed in:
regno is being set to UNW_ARM_RA_AUTH_CODE (0x8F) instead of 0, and in
one case, regclass is _UVRSC_CORE instead of _UVRSC_PSEUDO.
As a result, those calls to _Unwind_VRS_{Get,Set} return
_UVRSR_FAILED, which their callers ignore. So if you compile in the
AUTG instruction that actually validates the PAC, it will try to
validate what's effectively an uninitialised register as an
authentication code, and trigger a CPU fault even on correct exception
unwinding.
Reviewed By: danielkiss
Differential Revision: https://reviews.llvm.org/D128522
By adding noinline and calling fprintf before returning we ensure that
every function will have a distinct call frame and that the return address
will always be saved instead of saving the target in main as the result.
Before this change all backtraces were always backtrace -> main -> _start,
i.e. always exactly three entries. This happenend because all calls were
inlined in main() and the test just happenend to pass because there is at
least _start before main.
I found this while fixing some bugs in libunwind for CHERI and noticed that
the test was passing even though the code was completely broken.
Obtained from: https://github.com/CTSRD-CHERI/llvm-project
Reviewed By: #libunwind, ldionne, MaskRay
Differential Revision: https://reviews.llvm.org/D126611
This fixes unwinding in boundary cases on ARM with SEH.
In the case of ARM/Thumb, disp->ControlPc points at the following
instruction, with the thumb bit set. Thus by decrementing 1,
it still points at the next instruction. To achieve the desired
effect of pointing at the previous instruction, one first has to strip
out the thumb bit, then do the decrement by 1 to reach the previous
instruction.
When libcxxabi looks for call site ranges, it already does
`_Unwind_GetIP(context) - 1` (in `scan_eh_tab` in
libcxxabi/src/cxa_personality.cpp), so we shouldn't do the
corresponding `- 1` multiple times.
In the case of libcxxabi on Thumb, `funcStart` (still in `scan_eh_tab`)
may have the thumb bit set. If the program counter address is
decremented both in libunwind (first removing the thumb bit, then
decremented), and then libcxxabi decrements it further, and compares
with a `funcStart` with the thumb bit set, it could point to one byte
before the start of the call site.
Thus: This modification makes libunwind with SEH work with libcxxabi
on Thumb, in settings where libunwind and libcxxabi worked fine with
Dwarf before.
For existing cases with libunwind with SEH (on x86_64 and aarch64),
this modification doesn't break any of my testcases.
Differential Revision: https://reviews.llvm.org/D126869
There's no such corresponding code for ARM64 (which has been working
in production for years). The SEH version of the Unwind functions
(e.g. `_Unwind_GetLanguageSpecificData`) doesn't use these fields.
The `_Unwind_ForcedUnwind` function would need these bits though,
but that's not used in normal C++ exception unwinding.
Differential Revision: https://reviews.llvm.org/D126868
Check `__SEH__` when checking if ARM EHABI should be implied,
similarly to 4a3722a2c3dff1fe885cc38bf43d3c095c9851e7 / D126866.
Fix a warning by using the right format specifier (PRIxPTR instead
of PRIx64), and add a double->float cast in a codepath that hasn't
been built so far.
This is enough to make SEH unwinding of itanium ABI exceptions on
ARM mostly work - one specific issue is fixed in a separate follow-up
patch.
Differential Revision: https://reviews.llvm.org/D126867
