| Age | Commit message (Collapse) | Author |
|---|
|
(#133876)
We plan to replace the existing mechanism for overriding detection with
one that doesn't require the use of a special section as an alternative
to llvm/llvm-project#120805 which had other downsides.
This change is a pure refactoring that lays the foundation for a
subsequent change that will introduce the new detection mechanism.
|
|
Reverts llvm/llvm-project#120805
This change while desirable has two issues we discovered:
- It is incompatible with `-funique-internal-linkage-names`, see
https://github.com/llvm/llvm-project/pull/120805#discussion_r1913709817
- It is incompatible with `-fvisibility-global-new-delete=force-hidden`,
see
https://github.com/llvm/llvm-project/issues/123224#issuecomment-2607963878
We were hoping to address both of these issues with
https://github.com/llvm/llvm-project/pull/122983, but that change has
other issues we haven't yet managed to resolve. For now, we have decided
to revert the change to avoid shipping a broken feature in LLVM 20, and
we plan to follow up with a new approach post branch.
|
|
This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.
This is a reland of https://github.com/llvm/llvm-project/pull/114961
which addresses the issue reported by downstream users. Specifically,
the two differences from the previous version are:
* The internal `symbol##_impl__` symbol in the Mach-O implementation is
annotated with `__attribute__((used))` to prevent LTO from deleting it
which we've seen in the previous version.
* `__is_function_overridden` is marked as `inline` so these symbols are
placed in a COMDAT (or fully inlined) to avoid duplicate symbol errors
which we've seen in the previous version.
|
|
This reverts commit 62bd10f7d18ca6f544286767cae2c9026d493888.
Breaks building with -flto=thin, see
https://github.com/llvm/llvm-project/pull/114961#issuecomment-2555754056
|
|
This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.
|
|
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
|
|
This is an internal API and the name should reflect that.
This is a reland of #108887.
|
|
This reverts commit 33bc6cf619ac8d49232b1bc29ac7d38951583221.
Reason: broke Android buildbot (https://lab.llvm.org/buildbot/#/builders/186/builds/2517)
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm_build64/bin/clang++ -DHAVE___CXA_THREAD_ATEXIT_IMPL -DLIBCXX_BUILDING_LIBCXXABI -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS="" -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCXXABI_BUILDING_LIBRARY -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_LINK_PTHREAD_LIB -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/libcxxabi/../libcxx/src -I/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/lib/fuzzer/libcxx_fuzzer_aarch64/include/c++/v1 -I/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/libcxxabi/include --target=aarch64-linux-android24 --sysroot=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot --gcc-toolchain=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64 -B/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64 -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -std=c++23 -fPIC -nostdinc++ -fstrict-aliasing -fno-exceptions -D_DEBUG -UNDEBUG -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -fvisibility=hidden -fvisibility-global-new-delete=force-hidden -MD -MT libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/abort_message.cpp.o -MF libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/abort_message.cpp.o.d -o libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/abort_message.cpp.o -c /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/libcxxabi/src/abort_message.cpp
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/libcxxabi/src/abort_message.cpp:64:5: error: use of undeclared identifier 'android_set___abort_message'; did you mean 'android_set_abort_message'?
64 | android_set___abort_message(buffer);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| android_set_abort_message
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/libcxxabi/src/abort_message.cpp:18:25: note: 'android_set_abort_message' declared here
18 | extern "C" void android_set_abort_message(const char* msg);
| ^
1 error generated.
|
|
This is an internal API and the name should reflect that.
|
|
(#69498)
In D144319, Clang tried to land a change that would cause some functions
that are not supposed to return nullptr to optimize better. As reported
in https://reviews.llvm.org/D144319#4203982, libc++ started seeing
failures in its CI shortly after this change was landed.
As explained in D146379, the reason for these failures is that libc++'s
throwing `operator new` can in fact return nullptr when compiled with
exceptions disabled. However, this contradicts the Standard, which
clearly says that the throwing version of `operator new(size_t)` should
never return nullptr. This is actually a long standing issue. I've
previously seen a case where LTO would optimize incorrectly based on the
assumption that `operator new` doesn't return nullptr, an assumption
that was violated in that case because libc++.dylib was compiled with
-fno-exceptions.
Unfortunately, fixing this is kind of tricky. The Standard has a few
requirements for the allocation functions, some of which are impossible
to satisfy under -fno-exceptions:
1. `operator new(size_t)` must never return nullptr
2. `operator new(size_t, nothrow_t)` must call the throwing version and
return nullptr on failure to allocate
3. We can't throw exceptions when compiled with -fno-exceptions
In the case where exceptions are enabled, things work nicely.
`new(size_t)` throws and `new(size_t, nothrow_t)` uses a try-catch to
return nullptr. However, when compiling the library with
-fno-exceptions, we can't throw an exception from `new(size_t)`, and we
can't catch anything from `new(size_t, nothrow_t)`. The only thing we
can do from `new(size_t)` is actually abort the program, which does not
make it possible for `new(size_t, nothrow_t)` to catch something and
return nullptr.
This patch makes the following changes:
1. When compiled with -fno-exceptions, the throwing version of `operator
new` will now abort on failure instead of returning nullptr on failure.
This resolves the issue that the compiler could mis-compile based on the
assumption that nullptr is never returned. This constitutes an API and
ABI breaking change for folks compiling the library with -fno-exceptions
(which is not the general public, who merely uses libc++ headers but use
a shared library that has already been compiled). This should mostly
impact vendors and other folks who compile libc++.dylib themselves.
2. When the library is compiled with -fexceptions, the nothrow version
of `operator new` has no change. When the library is compiled with
-fno-exceptions, the nothrow version of `operator new` will now check
whether the throwing version of `operator new` has been overridden. If
it has not been overridden, then it will use an implementation
equivalent to that of the throwing `operator new`, except it will return
nullptr on failure to allocate (instead of terminating). However, if the
throwing `operator new` has been overridden, it is now an error NOT to
also override the nothrow `operator new`. Indeed, there is no way for us
to implement a valid nothrow `operator new` without knowing the exact
implementation of the throwing version.
In summary, this change will impact people who fall into the following
intersection of conditions:
- They use the libc++ shared/static library built with `-fno-exceptions`
- They do not override `operator new(..., std::nothrow_t)`
- They override `operator new(...)` (the throwing version)
- They use `operator new(..., std::nothrow_t)`
We believe this represents a small number of people.
Fixes #60129
rdar://103958777
Differential Revision: https://reviews.llvm.org/D150610
|
|
This patch removes the noexcept specifier introduced in #69407 since the
Standard allows a new handler to throw an exception of type bad_alloc
(or derived from it). With the noexcept specifier on the helper
functions, we would immediately terminate the program.
The patch also adds tests for the case that had regressed.
Co-authored-by: Alison Zhang <alisonzhang@ibm.com>
|
|
(#69407)
This will make it easier to implement new(nothrow) without calling the
throwing version of new when exceptions are disabled. See
https://llvm.org/D150610 for the full discussion.
|
|
This makes it a lot easier to make wide ranging changes like I am
about to do in https://llvm.org/D150610.
|
|
|
|
This allows mechanically copying any changes made to `operator new`
from libc++ into libc++abi as-is. This is also a step towards
de-duplicating this code entirely.
Differential Revision: https://reviews.llvm.org/D153035
|
|
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
|
|
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.
|
|
|
|
We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.
Differential Revision: https://reviews.llvm.org/D97700
|
|
In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot to update the definition in
libc++ (damn code duplication!). Then, in d4a1e03c5fb5, I synced the
definitions across libc++ and libc++abi, but I did it the wrong way around.
I re-added the if() checks to libc++abi instead of removing them from libc++.
In ef74f0fdc339, we re-removed the if() check from operator delete, but
only in libc++abi. This patch corrects this mess and removes it
consistently in libc++ and libc++abi.
Differential Revision: https://reviews.llvm.org/D93473
|
|
Similar to D52401. Normally operator delete is defined in libc++abi
(LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is off by default).
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
free on MSDN:
If memblock is NULL, the pointer is ignored and free immediately returns.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D93339
|
|
Differential Revision: https://reviews.llvm.org/D43159
|
|
There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of having
the same logic all over the place, extract the logic into a pair of
helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.
The code in libcxxabi/src/fallback_malloc.cpp looks like it could be
simplified after this change -- I purposefully did not simplify it
further to keep this change as straightforward as possible, since it
is touching very important parts of the library.
Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp
are basically the same -- I just kept both source files in sync.
The underlying reason for this refactoring is to make it easier to support
platforms that provide aligned allocation through C11's aligned_alloc
function instead of posix_memalign. After this change, we'll only have
to add support for that in a single place.
Differential Revision: https://reviews.llvm.org/D91379
|
|
Various definitions from libcxx need to be set in the same way
as if building libcxx itself.
Differential Revision: https://reviews.llvm.org/D90476
|
|
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
|
|
llvm-svn: 344208
|
|
_LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D49914
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50008
llvm-svn: 338475
|
|
llvm-svn: 302755
|
|
Summary:
Currently both libc++ and libc++abi provide definitions for new/delete. However libc++abi's definitions haven't been updated to include aligned new/delete or sized deallocation.
I don't see any reason why libc++abi shouldn't provide these newer overloads.
This patch copies libc++'s implementation of `new/delete` into libc++abi so that it's now up to date.
After applying this patch I plan to fix a longstanding bug where both libc++ and libc++abi provide definitions for new/delete.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, rmaprath, jroelofs
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30514
llvm-svn: 296787
|
|
This patch cleans up how libc++abi handles the definitions for new/delete.
It is in preperation for upcoming changes to fix how both libc++ and libc++abi
handle new/delete.
The primary changes in this patch are:
* Move the definitions for bad_array_length and bad_new_array_length
into stdlib_exception.cpp. This way stdlib_new_delete.cpp only
contains new/delete.
* Rename cxa_new_delete.cpp -> stdlib_new_delete.cpp for consistency
with other files.
* Add a FIXME regarding when stdlib_new_delete.cpp is actually compiled
as part of the dylib.
llvm-svn: 296715
|
