27ce26b066 added the new option
-fvisibility-global-new-delete=, where -fvisibility-global-new-delete=force-hidden
is equivalent to the old option -fvisibility-global-new-delete-hidden.
At the same time, the old option was deprecated.
Test for and use the new option form first; if unsupported, try
using the old form.
This avoids warnings in the MinGW builds, if built with Clang 18 or
newer.
(cherry picked from commit 1f973efd335f34c75fcba1ccbe288fd5ece15a64)
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is
that, FP64 and FP32 have different way to save/restore FPRs. If
libunwind is built as FPXX, we have no idea which one should we use.
It's not due to the code bug, but rather the nature of FPXX.
FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0
(FP32).
So that FPXX binaries can link with both FP64 and FP32 ones, aka.
FPXX + FP32 -> FP32
FPXX + FP64 -> FP64
While for libunwind, we should save/restore all of FPRs. If we use FPXX,
we can only save/restore a common subset of FPRs, instead of superset.
If libunwind is built as FP64, it will interoperatable with FPXX/FP64
APPs, and if it is built as FP32, it will interoperatable with
FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are
FP32.
So if the compiler is FPXX, which is the default value of most
toolchain, let's switch it to FP64.
Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>
(cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
Commit fc1c478709 added includes of <signal.h> and <errno.h> to
UnwindCursor.hpp. The library previously built on platforms where these
headers are not provided. These headers should be included only in the
case where they are actually needed, i.e. on Linux.
Fix this issue
[#76957](https://github.com/llvm/llvm-project/issues/76957)
Libgcc provides __register_frame to register a dynamic .eh_frame
section, while __unw_add_dynamic_eh_frame_section can be used to do the
same in libunwind. However, the address after dynamic .eh_frame are
padding with 0 value, it will be identified as
legal CIE. And __unw_add_dynamic_eh_frame_section will continue to parse
subsequent addresses until illegal memory or other sections are
accessed.
This patch adds length formal parameter for dynamic registration.
This applies the same change as in
760261a3da (where they were applied to
libcxxabi and libcxx) to libunwind as well.
These options can reasonably be set either as an absolute or relative
path, but if set as type PATH, they are rewritten from relative into
absolute relative to the build directory, while the relative form is
intended to be relative to the install prefix.
This patch adds a configuration of the libc++ test suite that enables
optimizations when building the tests. It also adds a new CI
configuration to exercise this on a regular basis. This is added in the
context of [1], which requires building with optimizations in order to
hit the bug.
[1]: https://github.com/llvm/llvm-project/issues/68552
process_vm_readv is generally considered dangerous from a syscall
perspective, and is frequently blanket banned in seccomp filters such as
those in Chromium and ChromiumOS. We can get the same behaviour during
the invalid PC address case with the raw SYS_rt_sigprocmask syscall.
Testing to ensure that process_vm_readv does not appear, I ran the
output of check-unwind on an ARM64 device under strace. Previously,
bad_unwind_info in particular would use process_vm_readv, but with this
commit, it now no longer uses it:
```
strace test/Output/bad_unwind_info.pass.cpp.dir/t.tmp.exe \
|& grep process_vm_readv
```
The libunwind unittests were also tested on ARM64 ChromeOS (Gentoo
Linux) devices.
libunwind uses C-style and low-level C++, so the language standard
doesn't matter that much, but bumping to C++17 aligns with the rest of
LLVM and enables some features that would cause pedantic warnings in
C++11 (e.g. -Wc++17-attribute-extensions for [[fallthrough]]/
[[nodiscard]]/[[maybe_unused]]). (Contributors might use these features
unaware of the pedantic warnings).
Suggested-by: Christopher Di Bella <cjdb@google.com>
When we use the -nostdlib++ flag, we don't need to explicitly link
against compiler-rt, since the compiler already links against it by
default. This simplifies the flags that we need to use when building
with Clang and GCC, and opens the door to further simplifications since
most platforms won't need to detect whether libgcc and libgcc_s are
supported anymore.
Furthermore, on platforms where -nostdlib++ is used, this patch prevents
manually linking compiler-rt *before* other system libraries. For
example, Apple platforms have several compiler-rt symbols defined in
libSystem.dylib. If we manually link against compiler-rt, we end up
overriding the default link order preferred by the compiler and
potentially using the symbols from the clang-provided libclang_rt.a
library instead of the system provided one.
Note that we don't touch how libunwind links against compiler-rt when it
builds the .so/.a because libunwind currently doesn't use -nodefaultlibs
and we want to avoid rocking the boat too much.
rdar://119506163
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.
Differential Revision: https://reviews.llvm.org/D154246
`LIBCXXABI_SYSROOT`, `LIBCXXABI_TARGET_TRIPLE` and
`LIBCXXABI_GCC_TOOLCHAIN` are not supported anymore. Based on the
comment, the warning should be removed after branching for LLVM 15.
libunwind uses a minimal set of necessary standard library functions,
basically just `memset` and `memcpy`. There is a single use of `strcpy`
to copy the bytes `"CLNGUNW"` into a `uint64_t` object. This is both an
arguably odd use of the `strcpy` function as well as it unnecessarily
widens the set of library functions that must be available to build
libunwind, which can be an obstacle in baremetal scenarios. This change
simply replaces this one `strcpy` with the more fundamental `memcpy`.
This will allow for configuring tests according to AIX version.
Reviewed By: daltenty, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D149660
This PR adds `static_cast` to the value returned from `getLR()` in the
AIX unwinder to avoid warning in case `-Wconversion` is specified to
build in 32-bit mode.
Summary:
The implementation of AIX unwinder gets the return address from the link area of the stack frame of a function and uses the return address to walk up functions. However, when unwinding starts from a signal handler and the function that raised the signal happens to be a leaf function and it does not have its own stack frame, the return address of the stack frame of the leaf function points to the caller of the function that calls the leaf function because the leaf function and its caller share the same stack frame. As a result, the caller of the leaf function is skipped. This patch fixes the problem by saving the LR value in sigcontext when the unwinder hits the signal handler trampoline frame and using it as the return address of the leaf function. The LR value from sigcontext is saved in the unwinding context slot for LR currently unused.
Reviewed by: stephenpeckham
Differential Revision: https://reviews.llvm.org/D158655
I was running the tests with baremetal picolibc which has a linker
script that __eh_frame_start==__eh_frame_end (not equal to zero) in
case there is no .eh_frame_hdr.
I noticed that libunwind was trying to read nonsense data because it
was printing messages such as
`libunwind: unsupported .eh_frame_hdr version: 20 at
8000d30814`
This change adds a ehHdr size check to avoid reading this out-of-bounds
data and potentially crashing.
All but one callsite were actually passing start+length arguments.
This should not have any functional change since the end argument is
almost always ignored.
I noticed this while debugging some incorrect error messages being
printed while running the testsuite baremetal (using binaries that did
not have a valid eh_frame_hdr section): the tests print
`libunwind: unsupported .eh_frame_hdr version: 20 at
8000d30814`
because
libunwind is reading nonsense data for .eh_frame_hdr.
Since 78d649a417 the recommended way to
pass an executor is to use the _TEST_PARAMS variable, which means we now
pass more complicated value (including ones that may contain multiple
`=`) as part of this variable. However, the `REGEX REPLACE` being used
has greedy matches so everything up to the last = becomes part of the
variable name which results in invalid syntax in the generated lit
config file.
This was noticed due to builder failures for those using the
CrossWinToARMLinux.cmake cache file.
---------
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
Change PRIu32 to PRIxPTR to avoid type warning of debug printf since VE
uses 64 bits SjLj. I don't use PRIuPTR since the print message has
0x-prefix from the beginning. I also change related PRIuPTR to PRIxPTR
since those uses 0x-prefix too.
This is useful when trying to run multiple tests with different
arguments to the executor script. This is needed in my case since I
do not know the correct ssh connection arguments when building libc++.
The testing script I have spawns multiple QEMU instances that listen on
a given port on localhost and runs lit with the --num-shards/--run-shard
argument. In order to connect each shard to the right QEMU instances I
need to customize the arguments passed to ssh.py (--extra-ssh-args and
--extra-scp-args) but can't do this at configure time since the target
port is only known when running the tests but not when calling CMake.
This change allows me to pass `executor=ssh.py <args>` to lit once I
know
the right hostname/port for running the tests.
This also deprecates the `LIB{CXX,CXXABI,UNWIND}_EXECUTOR` CMake
variable
as the same can be achieved by adding `executor=...` to the
`LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS` variable.
I was trying to run the tests on FreeBSD and noticed that we weren't
printing symbol names. It turns out this is because of the missing
-Wl,--export-dynamic flag. Instead of hardcoding the name of the flag
and only passing it for Linux hosts, use a pre-existing CMake variable
instead. I was not aware of this flag, but it appears to have been
supported for the past 16 years (with support for more platforms added
later):
66d1930f56
Avoid following prototype related warning.
Unwind-sjlj.c:85:75: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
This adds Wasm-specific libunwind port to support Wasm exception
handling (https://github.com/WebAssembly/exception-handling).
Wasm EH requires `__USING_WASM_EXCEPTIONS__` to be defined. This adds
`Unwind-wasm.c`, which defines libunwind APIs for Wasm. This also adds a
`thread_local` struct of type `_Unwind_LandingPadContext`, which serves
as a medium for input/output data between the user code and the
personality function. How all these work is explained in
https://github.com/WebAssembly/tool-conventions/blob/main/EHScheme.md.
(The doc is old and "You Shouldn't Prune Unreachable Resumes" section
doesn't apply anymore, but otherwise it should be good)
The bulk of these changes was added back in Mar 2020 in
https://github.com/emscripten-core/emscripten/pull/10577 to emscripten
repo and has been used ever since. Now we'd like to upstream this so
that other toolchains that don't use emscripten libraries, e.g., WASI,
can use this too.
Companion patch: D158918
Reviewed By: dschuff, #libunwind, phosek
Differential Revision: https://reviews.llvm.org/D158919
On Apple platforms, we always support the -nostdlib++ flag. Hence, it is
not necessary to manually link against system libraries. In fact, doing
so causes us to link against libSystem explicitly, which messes up with
the order of libraries we should use. Indeed:
Before patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF)
===========================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libc++abi.1.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
After patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF)
===========================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
Before patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON)
=======================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libunwind.1.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
After patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON)
======================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
As we can see, libSystem appears before the just-built libraries before
the patch, which causes the libunwind.dylib bundled in libSystem.dylib
to be used instead of the just-built libunwind.dylib.
We didn't notice the issue until recently when I tried to update the
macOS CI builders to macOS 13.5, where it is necessary to use the right
libunwind library (the exact reason still needs to be investigated).
`unw_getcontext` saves the caller's registers in the context. However,
if the caller of `unw_getcontext` is in a different module, the glue
code of `unw_getcontext` sets the TOC register (r2) with the new TOC
base and saves the original TOC register value in the stack frame. This
causes the incorrect TOC value is used when the caller steps up frames,
which fails libunwind LIT test case `unw_resume.pass.cpp`. This PR fixes
the problem by using the original TOC register value saved in the stack
if the caller is in a different module and enables `unw_resume.pass.cpp`
on AIX.
Previously this was based on target architecture, but
that makes very little sense--frame API availability is generally
for libgcc compatibility and that is dependent on runtime
needs rather than target architecture.
Default this to on, so as not to remove the apis from
environments that already have them.
The functions this macro protects are stubs for libgcc-compatibility.
Today, libunwind as a drop-in replacement for libgcc_eh links on x86,
x86_64, and powerpc, but not aarch64, which doesn't really make
sense. As there is nothing architecture specific about these, they
should be provided everywhere or nowhere.
The target-specific protection goes all the way back to the original
code contribution in 312fcd0e1c from
2013, so the original reason is lost to history, and probably not
relevant today.
Differential Revision: https://reviews.llvm.org/D158011
HI/LO registers have been removed in MIPSr6. Save and restore them only for pre-R6.
We keep the memory space for the registers so that we can use the same register indexes for
r6 and pre-r6.
Fixes: #60682
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D156283
https://reviews.llvm.org/D144252 removed -Wno-unused-function from the
libunwind build, but we have an unused function when you're building for
armv7 without assertions. Mark that function as possibly unused to avoid
the warning, and mark the parameter as a const pointer while I'm here to
make it clear that nothing is modified by a debugging function.
Reviewed By: #libunwind, philnik
Differential Revision: https://reviews.llvm.org/D156496
Add flags allowing to use compile flags and libraries provided in cache with libunwind.
Similar flags are already present in libc++ and libc++abi CMakeLists files.
Differential Revision: https://reviews.llvm.org/D150252
CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D152100
This reverts commit d763c6e5e2.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
This reverts commit 65429b9af6.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f8.
