Clang wants to enable this flag by default, but libc++ isn't working with it yet.
Reviewed By: Mordante, #libc, #libc_abi, EricWF
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144667
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
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
Summary:
The personality routine for the legacy AIX xlclang++ compiler uses the stack slot reserved for compilers to pass the exception object to the landing pad. The landing pad retrieves the exception object with a call to the runtime function __xlc_exception_handle(). The current implementation incorrectly assumes that __xlc_exception_handle() should go up one stack frame to get to the stack frame of the caller of __xlc_exception_handle(), which is supposedly the stack frame of the function containing the landing pad. However, this does not always work, e.g., the xlclang++ compiler sometimes generates a wrapper of __xlc_exception_handle() and calls the wrapper from the landing pad for optimization purposes. This patch changes the implementation to unwind the stack from __xlc_exception_handle() and skip frames not associated with functions that are C++ EH-aware until a frame associated with a C++ EH-aware function is found and then retrieving the exception object with the expectation that the located frame is the one that the personality routine installed as it transferred control to the landing pad.
Reviewed by: cebowleratibm, hubert.reinterpretcast, daltenty
Differential Revision: https://reviews.llvm.org/D143010
They are not needed in <new> -- in fact they are only needed in .cpp files.
Getting those out of the way makes the headers smaller and also makes it
easier to use the library on platforms where aligned allocation is not
available.
Differential Revision: https://reviews.llvm.org/D139231
This at least allows us to stand up libc++ FreeBSD CI and avoid future
regressions. The failures do need to be addressed, and can be done
iteratively.
Reviewed By: philnik, Mordante
Differential Revision: https://reviews.llvm.org/D141542
__ANDROID__ is a built-in compiler macro, but __BIONIC__ is defined by
the libc header.
Reviewed By: #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D137128
The size of long double in LoongArch (both LA32 and LA64) is 16 bytes, thus
the mangled_size should be 32.
This is same as RISCV's change in D126480.
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D138981
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.
Summary:
libc++abi LIT test case vec_reg_restore.pass.cpp for AIX uses instructions mtvsrd and mfvsrd that are only available on Power8 CPU and higher, and therefore, fails on Power7 which is supported by the current AIX Clang. This patch replaces mtvsrd/mfvsrd with vector instructions available on Power7.
Reviewed by: nemanjai
Differential Revision: https://reviews.llvm.org/D138667
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
This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting this to
solve https://github.com/android/ndk/issues/1200 [1], but every compiler
and platform libc++abi supports should have thread_local by now, so we
can just get rid of the fallback implementation and simplify things
significantly (including removing the now unused fallback calloc).
[1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596
Reviewed By: #libc_abi, MaskRay, ldionne
Differential Revision: https://reviews.llvm.org/D138461
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
Sometimes libc++'s stddef.h wrapper gets included, which defines
::nullptr_t. This test is compiled with -Wshadow -Werror, so shadowing
::nullptr_t with a nullptr_t in main is an error. Include cstddef,
which is guaranteed to define std::nullptr_t in C++11 and forward.
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D137127
Summary:
The existing implementation of the personality for legacy IBM xlclang++ compiler generated code passes the address of exception object in r14 for the landing pad to retrieve with a call to __xlc_exception_handle(). This clobbers the content of r14 in user code (and potentially, when running cleanup actions, the address of another exception object being passed). This patch changes to use the stack slot reserved for compilers to pass the address. It has been confirmed that xlclang++-generated code does not use this slot.
This is a follow-on of the origibal patch below with a change in comments.
https://reviews.llvm.org/rGa499051f10a2d0150b60c14493558476039f701a
Reviewed by: hubert.reinterpretcast, cebowleratibm
Differential Revision: https://reviews.llvm.org/D136257
Summary:
The existing implementation of the personality for legacy IBM xlclang++ compiler generated code passes the address of exception object in r14 for the landing pad to retrieve with a call to __xlc_exception_handle(). This clobbers the content of r14 in user code (and potentially, when running cleanup actions, the address of another exception object being passed). This patch changes to use the stack slot reserved for compilers to pass the address. It has been confirmed that xlclang++-generated code does not use this slot.
Reviewed by: hubert.reinterpretcast, cebowleratibm
This open codes the use of lower-bound when looking for an operator
encoding. Using std::lower_bound can result in symbol references to
the C++ library and that breaks the ABI demangler, which mandates no
such dependency.
Differential Revision: https://reviews.llvm.org/D135799
Fixes: https://github.com/llvm/llvm-project/issues/58117
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.
Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.
That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.
The buffer reset member function is never used, and is deleted.
Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.
a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes. We need to avoid the UB of passing nullptr to
memcpy.
b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.
The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.
But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122604
Sadly the demangler copies have diverged. This resyncs them by
a) pulling the meaningful llvm changes into libcxxabi's gold copy.
b) rerunning the sync script.
I notice uses of placement new, which assume the allocator succeeds --
that's incorrect in general, but an orthogonal problem.
Reviewed By: bader
Differential Revision: https://reviews.llvm.org/D135446
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
This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces:
# ASCII version of libc++ named as libc++_a.so
# Script to rename DLL name inside the generated side deck
# Various names for dataset members where DLL libraries and their side decks will reside
# Add the following options:
- LIBCXX_SHARED_OUTPUT_NAME
- LIBCXX_ADDITIONAL_COMPILE_FLAGS
- LIBCXX_ADDITIONAL_LIBRARIES
- LIBCXXABI_ADDITIONAL_COMPILE_FLAGS
- LIBCXXABI_ADDITIONAL_LIBRARIES
**Background and rational of this patch**
The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name.
If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL.
Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D118503
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
Under some circumstances there is no struct _Unwind_Exception, it's just
an alias to another struct. This would result in an error like this:
libcxxabi/test/forced_unwind3.pass.cpp:50:77: error: typedef '_Unwind_Exception' cannot be referenced with a struct specifier
static _Unwind_Reason_Code stop(int, _Unwind_Action actions, type, struct _Unwind_Exception*, struct _Unwind_Context*,
^
<...>/lib/clang/15.0.0/include/unwind.h:68:38: note: declared here
typedef struct _Unwind_Control_Block _Unwind_Exception; /* Alias */
^
This seems to have been an issue since the test was first added in
D109856, except that it didn't surface with Clang 14 because the code
is filtered out by the preprocessor if `__clang_major__ < 15`.
Reviewed By: danielkiss, mstorsjo, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D132873
Otherwise, we would end up passing `-lNOTFOUND` to the compiler, which
caused various compiler checks to fail and ended up breaking the build
in the most obscure ways. For example, checks for -faligned-allocation
would fail because the compiler would complain about an unknown library
called NOTFOUND, and we would end up not passing -faligned-allocation
anywhere in our build. This is madness.
An even better alternative would be to simply FATAL_ERROR if we don't
find the builtins library. However, it seems like our build has been
working fine without finding it for a while, so instead of making a
bunch of builds fail, we can figure out why linking against compiler-rt
doesn't actually seem to be required in a follow-up, and perhaps
relax that.
This commit reverts the following commits:
- 952f90b72b3546d6b6b038d410f07ce520c59b48
- e6a0800532bb409f6d1c62f3698bdd6994a877dc (D132298)
- 176db3b3ab25ff8a9b2405f50ef5a8bd9304a6d5 (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
This allows `-DLLVM_ENABLE_RUNTIMES=libcxxabi` to work.
This functionality was removed in D125561 (among other such removals) as
dead code, because it was only available as part of the standalone build
before.
The functionality as added back as it was, except `target_include_directories` is used instead of the cruder `target_compile_options` (with an MSVC vs not MSVC conditional split). That is just wholly better.
Reviewed By: phosek, #libc_abi
Differential Revision: https://reviews.llvm.org/D132298
This aligns the ``heap[]`` array in ``fallback_malloc.cpp`` to ensure
that it can be safely cast to ``heap_node*``, and also adjusts the
allocation algorithm to ensure that every allocated block has the
alignment requested by ``__attribute__((aligned))``, by putting the
block's ``heap_node`` header 4 bytes before an aligned address.
Patch originally by Eric Fiselier: this is an updated version of
D12669, which was never landed.
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D129842
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
We already link libunwind explicitly so avoid trying to link toolchain's
default libunwind which may be missing. This matches what we already do
for libcxx.
Differential Revision: https://reviews.llvm.org/D129469
This patch is to enable exception handling on the z/OS platform that is compatible with the existing z/OS runtime. No functionality of libcxxabi has been changed for other platforms. With this patch the hope is we can add z/OS as a platform to perform testing on any C++ ABI changes.
There is a primary difference for the z/OS implementation. On z/OS the thrown object is added to a linked list of caught and uncaught exceptions. The unwinder uses the top one as the current exception it is trying to find the landing pad for. We have to pop the top exception after we get it’s landing pad for our unwinder to correctly get any subsequent rethrows or nested exception calls.
Differential Revision: https://reviews.llvm.org/D99913
