Age | Commit message (Collapse) | Author |
|
i386 Windows
On Windows on i386, C++ member functions use a different calling
convention (`__thiscall`) than the default one for regular functions
(`__cdecl`). (On Windows on architectures other than i386, both calling
convention attributes are no-ops.)
This matches how libstdc++ declares these types.
This fixes the std/thread/futures/futures.{shared,unique}_future/dtor.pass.cpp
tests on i386 mingw.
Differential Revision: https://reviews.llvm.org/D124990
|
|
The fix for D111703 clobbered r4 both to:
- Save/restore the original lr.
- Load the address of _Unwind_Resume for LIBCXXABI_BAREMETAL.
This patch saves and restores lr without clobbering any extra
registers.
For LIBCXXABI_BAREMETAL, it is still necessary to clobber one extra
register to hold the address of _Unwind_Resume, but it seems better to
use ip/r12 (intended for linker veneers/trampolines) than r4 for this
purpose.
The function also clobbers r0 for the _Unwind_Resume function's
parameter, but that is unavoidable.
Reviewed By: danielkiss, logan, MaskRay
Differential Revision: https://reviews.llvm.org/D121432
|
|
This change consists of just adding 'BTI' to the prologue of Arm assembly
functions, which is just the one: __cxa_end_cleanup
This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:
https://developer.arm.com/documentation/ddi0553/latest
The following people contributed to this patch:
- Mikhail Maltsev
Reviewed By: lenary, danielkiss
Differential Revision: https://reviews.llvm.org/D112432
|
|
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
|
|
On Armv6-M the branch may not able to reach the _Unwind_Resume function because it's relocation(R_ARM_THM_JUMP11) is in -2048, 2047 range only.
Reviewed By: chill, stuij, lenary
Differential Revision: https://reviews.llvm.org/D113181
|
|
This reverts commit 3255578ee1dbb5561025ac89cd33ba08e8f26efb.
Failed buildbot's Armv7 builds:
https://lab.llvm.org/buildbot/#/builders/60/builds/5303
|
|
On Armv6-M the branch may not able to reach the _Unwind_Resume function because it's relocation(R_ARM_THM_JUMP11) is in -2048, 2047 range only.
Reviewed By: chill, stuij, lenary
Differential Revision: https://reviews.llvm.org/D113181
|
|
This is relanding commit da1d1a08694bbfe0ea7a23ea094612436e8a2dd0 .
This patch additionally addresses failures found in buildbots & post review comments.
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
|
|
_UnwindResume.""
This reverts commit b6420e575f3bbb6b6df848c0284d6b60eeb07350.
|
|
This is relanding commit da1d1a08694bbfe0ea7a23ea094612436e8a2dd0 .
This patch additionally addresses failures found in buildbots & post review comments.
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
|
|
This reverts commit da1d1a08694bbfe0ea7a23ea094612436e8a2dd0.
|
|
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
|
|
The file was a duplicate of atomic_support.h in libc++. Since we now
require the libc++ sources in order to build libc++abi, it's OK to
remove this duplication.
Thanks to @chandlerc for noticing this.
Differential Revision: https://reviews.llvm.org/D110103
|
|
This was changed from using the header to using a forward declaration in
c4600ccf891c, since older versions of the header didn't declare the
function. At this point, it's been declared for ~3.5 years, and it
should be pretty safe to assume that we can rely on the ASan interface
header to provide a declaration instead of needing to write our own.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D103003
|
|
|
|
llvm-svn: 373524
|
|
This reduces the (circular) dependency of libc++abi on a C++ standard
library. Outside of the demangler which uses fancier C++ features, the
only C++ headers now required by libc++abi are pretty much <new> and
<exception>, and that's because libc++abi defines some types that are
declared in those headers.
llvm-svn: 373381
|
|
llvm-svn: 373379
|
|
LLVM uses .h as its extension for header files.
Differential Revision: https://reviews.llvm.org/D65981
llvm-svn: 368604
|
|
Those are now hosted on GitHub.
rdar://problem/36557462
llvm-svn: 358191
|
|
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
|
|
https://reviews.llvm.org/D42242
llvm-svn: 344152
|
|
_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is currently used to
bring back std::unexpected, which is removed in C++17, but still needed
for libc++abi for backward compatibility.
This macro used to define in cxa_exception.cpp only, but actually
needed for all sources that touches exceptions.
So, a build-system-level macro is better fit to define this macro.
https://reviews.llvm.org/D46056
Patch from Taiju Tsuiku <tzik@chromium.org>!
llvm-svn: 331150
|
|
This is basically part 2 of r313694.
It's a little unfortunate that I had to copy-paste atomic_support.h,
but I don't really see any alternative.
The refstring.h changes are the same as the libcxx changes in r313694.
llvm-svn: 330162
|
|
Summary:
exception_header->exceptionDestructor is a void(*)(void*) function
pointer; however, it can point to destructors like std::
exception::~exception that don't match that type signature.
Reviewers: pcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: kcc, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45455
llvm-svn: 329629
|
|
C++17 removes `std::unexpected_handler`, but libc++abi needs it to define
`__cxa_exception`. When building against libc++, this is easily rectified by
telling libc++ we're building the library. We already do this in the other
places where we need these symbols.
Differential Revision: https://reviews.llvm.org/D42987
llvm-svn: 324542
|
|
object is sufficiently aligned.
r303175 annotated field unwindHeader of __cxa_exception with attribute
'aligned' to ensure the thrown object following the __cxa_exception
header was sufficiently aligned. This caused changes in the field
offsets of __cxa_exception relative to the start of the thrown object,
which was an ABI breaking change for some clients.
Instead of annotating field unwindHeader, this commit inserts extra
space before the header. This ensures the thrown object following the
header is sufficiently aligned without changing the field offsets, thus
avoiding any ABI breakages.
rdar://problem/25364625
rdar://problem/35556163
llvm-svn: 319123
|
|
compiler-rt recently added the __asan_handle_no_return() function that libc++abi
needs to use, however older versions of compiler-rt don't declare this interface
publicly and that breaks the libc++abi build.
This patch attempts to fix the issues by declaring the asan function explicitly,
so we don't depend on compiler-rt to provide the declaration.
llvm-svn: 313308
|
|
Summary:
compiler-rt recently added the `__asan_handle_no_return()` function that libc++abi needs to use, however older versions of compiler-rt don't provide this interface and that breaks the libc++abi build.
This patch attempts to fix the issues by using a macro to detect if `asan_interface.h` is new enough to provide the function.
See D37871
Reviewers: phosek, vitalybuka
Reviewed By: phosek, vitalybuka
Subscribers: dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D37872
llvm-svn: 313304
|
|
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37229
llvm-svn: 313215
|
|
__asan_handle_no_return"
This reverts commit r312606 because it's causing an error on
libcxx-libcxxabi-x86_64-linux-ubuntu-asan bot.
llvm-svn: 312609
|
|
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
This is a re-land of r311045, which has become safe after r311869
changed compiler-rt to declare __asan_handle_no_return.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37229
llvm-svn: 312606
|
|
__asan_handle_no_return"
This reverts commit r311045 because it's causing an error on
libcxx-libcxxabi-x86_64-linux-ubuntu-asan bot.
llvm-svn: 311047
|
|
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36599
llvm-svn: 311045
|
|
Summary: It's now completely empty, so we can remove it entirely.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31502
llvm-svn: 299129
|
|
Summary:
In 32 bit builds on a 64 bit system `std::malloc` does not return correctly aligned memory. This leads to undefined behavior.
This patch switches to using `posix_memalign` to allocate correctly aligned memory instead.
Reviewers: mclow.lists, danalbert, jroelofs, compnerd
Reviewed By: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25417
llvm-svn: 296952
|
|
Convention in libcxxabi is to use !defined(FOO) not !FOO.
Differential Revision: https://reviews.llvm.org/D30459
llvm-svn: 296612
|
|
Use the libc++abi visibility macros instead of pragmas or using
visibility attributes directly. Clean up redundant attributes on
definitions (where the declarations already have visibility attributes
applied, from either libc++ or libc++abi headers).
Introduce _LIBCXXABI_WEAK as a drive-by cleanup, which matches the
semantics of _LIBCPP_WEAK.
No functional change. Tested by building on Linux before and after this
change and verifying that the list of exported symbols is identical.
Differential Revision: https://reviews.llvm.org/D26949
llvm-svn: 296576
|
|
This patch adds the required leading underscore to those macros.
llvm-svn: 296567
|
|
r281179 Introduced an externally threaded variant of the libc++ library. This
patch adds support for a similar library variant for libc++abi.
Differential revision: https://reviews.llvm.org/D27575
Reviewers: EricWF
llvm-svn: 290888
|
|
This patch refactors all pthread uses of libc++abi into a separate API. This
is the first step towards supporting an externlly-threaded libc++abi library.
I've followed the conventions already used in the libc++ library for the same
purpose.
Patch from: Saleem Abdulrasool and Asiri Rathnayake
Reviewed by: compnerd, EricWF
Differential revisions:
https://reviews.llvm.org/D18482 (original)
https://reviews.llvm.org/D24864 (final)
llvm-svn: 284128
|
|
__cxa_eh_globals in case of dynamic memory exhaustion.
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
In this revision, some restrictions were added into the test to not
run it in unsuitable environments.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 283531
|
|
dynamic memory exhaustion.
The test breaks build bots.
llvm-svn: 282703
|
|
dynamic memory exhaustion.
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 282692
|
|
Align the naming / use of the macro LIBCXXABI_HAS_NO_THREADS to follow what we
have in libcxx. NFC.
llvm-svn: 282062
|
|
This commit adds SHF_ALLOC and SHF_EXECINSTR section flags to
`.text.__cxa_end_cleanup` section. This fixes a link error when we are
using integrated-as and `ld.gold` (with `-Wl,--gc-sections` and
`-Wl,--fatal-warnings`.)
Detailed Explanation:
1. There might be some problem with LLVM integrated-as. It is not
emitting any section flags for text sections. (This will be fixed in
an independent commit.)
2. `ld.gold` will skip the external symbols in the section without
SHF_ALLOC. This is the reason why `.text.__cxa_end_cleanup_impl`
section is discarded even though it is referenced by
`__cxa_end_cleanup()`.
This commit workaround the problem by specifying the section flags
explicitly.
Fix http://llvm.org/PR21292
llvm-svn: 256241
|
|
Mark functions and types with the appropriate visibility. This is particularly
useful for environments which explicitly indicate origin of functions (Windows).
This aids in generating libc++abi as a DSO which exposes only the public
interfaces.
llvm-svn: 254691
|
|
Cleanup some code with clang-format to make the following change easier to
identify material difference. NFC.
llvm-svn: 254690
|
|
Use `__builtin_offsetof` in place of `offsetof`. Certain environments provide a
macro definition of `offsetof` which may end up causing issues. This was
observed on Windows. Use `__builtin_offsetof` to ensure correct evaluation
everywhere. NFC.
llvm-svn: 253435
|
|
the libc++abi version. Reviewed as http://reviews.llvm.org/D10067
llvm-svn: 238827
|