| Age | Commit message (Collapse) | Author |
|---|
|
These functions have never been used outside the dylib, so there is no
point in exporting them.
|
|
There are some problems with our ABI list checking exposed by recent
compiler/cmake upgrades.
- For symcheck, there are typos in how XCOFF magic are defined, we
intended the second two digits to be a hex value, but our syntax doesn't
say that. Thus this will never match a valid XCOFF file.
- AIX triples can have version numbers. Those need to be discarded when
looking for an libc++ ABI list, like we do for other targets.
|
|
errors." (#148787)
Reverts llvm/llvm-project#148266
I'm reverting this temporarily, since the release branch is today and
this is ABI sensitive. Let's wait until after the branch so that we have
plenty time to discuss the patch.
|
|
(#148266)
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
|
|
```
----------------------------------------------
Benchmark old new
--------------------------- ------------------
BM_tolower_char<char> 1.64 ns 1.41 ns
BM_tolower_char<wchar_t> 1.64 ns 1.41 ns
BM_tolower_string<char> 32.4 ns 12.8 ns
BM_tolower_string<wchar_t> 32.9 ns 15.1 ns
BM_toupper_char<char> 1.63 ns 1.64 ns
BM_toupper_char<wchar_t> 1.63 ns 1.41 ns
BM_toupper_string<char> 32.2 ns 12.7 ns
BM_toupper_string<wchar_t> 33.0 ns 15.1 ns
```
|
|
instead of ABI (#127697)
We're currently adding `bad_function_call::what()` behind an ABI flag,
even though adding it is not an ABI break and can be handled through
availability.
|
|
This has multiple benefits:
- There is a single instance of our hash function, reducing object file
size
- The hash implementation isn't instantiated in every TU anymore,
reducing compile times
- Behind an ABI configuration macro it would be possible to salt the
hash
|
|
Technical issues have apparently been resolved and the node should be
back online.
Closes #117780
|
|
This refactors the standard stream implementation in multiple ways:
- The streams are now `stream_data` structs, which contain all the data
required for a stream
- The windows mangling is generated via a macro instead of having magic
strings for the different streams. (i.e. it's now only partially magic)
|
|
These symbols are never referenced directly outside the dylib, so we can
make them hidden instead. They are still in the dylib since can be
referenced through the `memory_resource*`, but dynamic linkers don't
have to do any work to deduplicate them.
|
|
1. remove unused __default_buffer_alignment
2. two __try_allocate_from_chunk are same, put it together
This patch refactor some code in monotonic_buffer_resource.
|
|
The pointer safety functions were never implemented by anyone in a
non-trivial way, which lead us to removing them entirely from the
headers when they were removed in C++23. This also means that just about
nobody ever called these functions, especially not in production code.
Because of that, we expect there to be no references in the wild to the
functions in the dylib. Because of that, this patch removes the symbols
from the dylib.
|
|
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
|
|
When the library was initially written, it was not built with hidden
visibility. In an attempt to reduce the number of symbols exported from
libc++, an explicit list of symbols to avoid exporting was passed to the
linker. This was only done on Apple platforms.
Since then, the library has moved on in several ways. First, we now
build with hidden visibility by default, so arbitrary symbols don't get
exported from the library for no reason. Second, we have proper
visibility control via source annotations, so we export exactly what we
want to, and we do that from the sources.
This patch removes the explicit list of symbols to avoid exporting from
the library, which at this point doesn't cover much anyways. The only
symbols we will now be exporting that we were not before are some
typeinfo names for implementation-detail types. While we technically
wouldn't have to export those (I don't think any user can get their
hands on those typeinfo names), that makes the library more consistent
on all platforms.
|
|
In 6a884a9aef39, I synchronized the export list of libc++abi to the
export list of libc++. From the linker's perspective, this caused these
symbols to be taken from libc++.dylib instead of libc++abi.dylib.
However, that can be problematic when back-deploying. Indeed, this means
that the linker will encode an undefined reference to be fullfilled by
libc++.dylib, but when backdeploying against an older system, that
symbol might only be available in libc++abi.dylib.
Most of the symbols that started being re-exported after 6a884a9aef39
turn out to be implementation details of libc++abi, so nobody really
depends on them and this back-deployment issue is inconsequential.
However, we ran into issues with a few of these symbols while testing
LLVM 19, which led to this patch. This slipped between the cracks and
that is why the patch is coming so long after the original patch landed.
In the future, a follow-up cleanup would be to stop exporting most of
the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
since they are implementation details that nobody should be relying on.
rdar://131984512
|
|
This adds a new `__cxa_call_terminate`, which GCC 14 generates calls to
now. Clang had `__clang_call_terminate` for the same use-case for a long
time. It also fixes a test that is enabled now, since GCC has the
`__has_feature` FTM now.
|
|
This patch makes libc++ build with -fsized-deallocation. That flag is
enabled by default in recent versions of Clang, so this patch will make
libc++ forward-compatible with ToT Clang.
|
|
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes #82107
|
|
and bad_function_call (#87390)
This patch uses our availability machinery to allow defining a key
function for bad_function_call and bad_expected_access at all times but
only rely on it when we can. This prevents compilers from complaining
about weak vtables and reduces code bloat and the amount of work done by
the dynamic linker.
rdar://111917845
|
|
Previously, the list of libc++abi symbols that we re-export from libc++
would be partly encoded in libc++abi (and re-exported automatically via
the cxxabi-reexports target), and partly hard-coded in
libcxx/lib/libc++abi.exp. The duplication of information led to symbols
not being exported from libc++ after being added to libc++abi when they
should have been.
This patch removes the duplication of information. After this patch, the
full list of symbols to re-export from libc++abi is handled by the
cxxabi-reexports target and is stored in libcxxabi.
The symbols newly re-exported from libc++ are mainly new fundamental
typeinfos and a bunch of functions and classes that are part of
libc++abi but are most likely implementation details. In the future, it
would be possible to try to trim down the set of what we export from
libc++abi (and hence what we re-export from libc++) to remove some
implementation detail symbols.
Fixes #79008
|
|
Having the test in the header requires including unistd.h on POSIX
platforms. This header has other declarations which may conflict with
code that uses named declarations provided by this header. For example
code using "int pipe;" would conflict with the function pipe in this
header.
Moving the code to the dylib means std::print would not be available on
Apple backdeployment targets. On POSIX platforms there is no transcoding
required so a not Standard conforming implementation is still a useful
and the observable differences are minimal. This behaviour has been done
for print before https://github.com/llvm/llvm-project/pull/76293.
Note questions have been raised in LWG4044 "Confusing requirements for
std::print on POSIX platforms", whether or not the isatty check on POSIX
platforms is required. When this LWG issue is resolved the
backdeployment targets could become Standard compliant.
This patch is intended to be backported to the LLVM-18 branch.
Fixes: https://github.com/llvm/llvm-project/issues/79782
|
|
|
|
std::make_exception_ptr (#65534)
This patch implements __cxa_init_primary_exception, an extension to the
Itanium C++ ABI. This extension is already present in both libsupc++ and
libcxxrt. This patch also starts making use of this function in
std::make_exception_ptr: instead of going through a full throw/catch
cycle, we are now able to initialize an exception directly, thus making
std::make_exception_ptr around 30x faster.
|
|
This commit adds ABI lists for the Android NDK.
Fixes: https://github.com/llvm/llvm-project/issues/69270
Differential Revision: https://reviews.llvm.org/D155341
|
|
Finishes implementation of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be synchronized
with the underlying stream?
Differential Revision: https://reviews.llvm.org/D156609
|
|
Since we use C++20 to build the dylib, we can use a lambda to do the
first-time initialization instead of emulating std::bind. This should
not change the behavior of the code at all, it merely simplifies it.
This removes a symbol from the dylib, however that symbol was only ever
used inside the dylib so it shouldn't break the ABI for anyone. I
confirmed that by searching for that symbol on the ABI boundary of a
large number of programs and couldn't find any references to that
function.
|
|
In the event the internal function __init is called with an empty string the code will take unnecessary extra steps, in addition, the code generated might be overall greater because, to my understanding, when initializing a string with an empty `const char*` "" (like in this case), the compiler might be unable to deduce the string is indeed empty at compile time and more code is generated.
The goal of this patch is to make a new internal function that will accept just an error code skipping the empty string argument. It should skip the unnecessary steps and in the event `if (ec)` is `false`, it will return an empty string using the correct ctor, avoiding any extra code generation issues.
After the conversation about this patch matured in the libcxx channel on the LLVM Discord server, the patch was analyzed quickly with "Compiler Explorer" and other tools and it was discovered that it does indeed reduce the amount of code generated when using the latest stable clang version (16) which in turn produces faster code.
This patch targets LLVM 18 as it will break the ABI by addressing https://github.com/llvm/llvm-project/issues/63985
Benchmark tests run on other machines as well show in the best case, that the new version without the extra string as an argument performs 10 times faster.
On the buildkite CI run it shows the new code takes less CPU time as well.
In conclusion, the new code should also just appear cleaner because there are fewer checks to do when there is no message.
Reviewed By: #libc, philnik
Spies: emaste, nemanjai, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D155820
|
|
This patch removes the symbols defined in the library for std::allocator_arg,
std::defer_lock, std::try_to_lock, std::adopt_lock, and std::piecewise_construct.
Those were defined in the library because we provided them in C++03 as an
extension, and in C++03 it was impossible to define them as `constexpr`
variables, like in the spec.
This is technically an ABI break since we are removing symbols from the
library. However, in practice, only programs compiled in C++03 mode who
take the address of those objects (or pass them as a reference) will have
an undefined ref to those symbols. In practice, this is expected to be
rare. First, those are C++11 features that we happen to provide in C++03,
and only the C++03 definition can potentially lead to code referencing
the dylib definition. So any code that is using these objects but compiling
in C++11 mode (as they should) is not at risk. Second, all uses of these
types in the library is done by passing those types by value to a function
that can get inlined. Since they are empty types, the compiler won't
generate an undefined reference if passed by value, since there's nothing
to pass anyway.
Long story short, the risk for code actually containing an undefined
reference to one of these types is rather small (but non-zero). I also
couldn't find any app on the App Store that referenced these symbols,
which supports my impression that this won't be an issue in practice.
Differential Revision: https://reviews.llvm.org/D145587
|
|
Fix a few typos and remove TODOs
|
|
__sort5 from the dylib
These instantiations were never visible, because they are only used in `__sort`, which is also explicitly instantiated in the dylib.
Reviewed By: ldionne, #libc
Spies: #libc_vendors, emaste, nemanjai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D142185
|
|
This matches the configuration used by the prospective FreeBSD CI runner.
Remove the (unused) ABI list created in my local environment.
This reverts commit eca9196dc8826b9455a2cdb57c52d51403cb742c.
Reviewed by: Mordante
Differential Revision: https://reviews.llvm.org/D141496
|
|
Generated via `nina generate-cxx-abilist`.
Reviewed By: Mordante, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D140431
|
|
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
|
|
This avoids emitting the VTable of `pmr::memory_resource` in every TU.
Reviewed By: ldionne
Spies: EricWF, nemanjai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D136196
|
|
|
|
This patch is the rebase and squash of three earlier patches.
It supersedes all three of them.
- D47111: experimental monotonic_buffer_resource.
- D47358: experimental pool resources.
- D47360: Copy std::experimental::pmr to std::pmr.
The significant difference between this patch and the-sum-of-those-three
is that this patch does not add `std::experimental::pmr::monotonic_buffer_resource`
and so on. This patch simply adds the C++17 standard facilities, and
leaves the `std::experimental` namespace entirely alone.
Differential Revision: https://reviews.llvm.org/D89057
|
|
With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is thrown
under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't
really make sense anymore.
Furthermore, I didn't want to use the name `__libcpp_abort_handler`,
since that would give the impression that the handler is called
whenever `std::abort()` is called, which is not the case at all.
Differential Revision: https://reviews.llvm.org/D130562
|
|
|
|
Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towards using the handler to handle other non-assertion-related
failures, like std::unreachable and an exception being thrown in
-fno-exceptions mode, which would improve user experience by including
additional information in crashes (right now, we call abort() without
additional information).
Differential Revision: https://reviews.llvm.org/D130507
|
|
|
|
Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.
This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.
Differential Revision: https://reviews.llvm.org/D127360
|
|
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.
Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).
Differential Revision: https://reviews.llvm.org/D128928
|
|
The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124165
|
|
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
|
|
I think this notion of libc++abi's version was relevant a long time ago
on Apple platforms when we were using a Xcode project to build the library.
As part of moving Apple's build to CMake, D59489 made it possible to
specify the "ABI version" of libc++abi in use. However, it's not possible
to build libc++abi with that old ABI anymore and we don't need the ability
to link against that version from libc++ anymore.
Hence, we can clean this up and stop falsely pretending that libc++abi
has more than one ABI version.
Differential Revision: https://reviews.llvm.org/D125687
|
|
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
|
|
Add missing commit SHAs in a few cases, and use "All Platforms" when
the change affected all platforms instead of explicitly listing the
platforms, since there's too many to list exhaustively.
|
|
|
|
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
|
