Revert "[libcxx] Use alias for detecting overriden function" (#124431)

Reverts llvm/llvm-project#120805

This change while desirable has two issues we discovered:

- It is incompatible with `-fu

Revert "[libcxx] Use alias for detecting overriden function" (#124431)

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.

show more ...

[libcxx] Use alias for detecting overriden function (#120805)

This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.

This is

[libcxx] Use alias for detecting overriden function (#120805)

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.

show more ...

Revert "[libcxx] Use alias for detecting overriden function (#114961)"

This reverts commit 62bd10f7d18ca6f544286767cae2c9026d493888.
Breaks building with -flto=thin, see
https://github.com/llvm/llvm

Revert "[libcxx] Use alias for detecting overriden function (#114961)"

This reverts commit 62bd10f7d18ca6f544286767cae2c9026d493888.
Breaks building with -flto=thin, see
https://github.com/llvm/llvm-project/pull/114961#issuecomment-2555754056

show more ...

[libcxx] Use alias for detecting overriden function (#114961)

This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.

[PAC] Make __is_function_overridden pauth-aware on ELF platforms (#107498)

Apparently, there are two almost identical implementations: one for
MachO and another one for ELF. The ELF bits somehow sl

[PAC] Make __is_function_overridden pauth-aware on ELF platforms (#107498)

Apparently, there are two almost identical implementations: one for
MachO and another one for ELF. The ELF bits somehow slipped while
https://github.com/llvm/llvm-project/pull/84573 was reviewed.

The particular implementation is identical to MachO case.

show more ...

[libcxx] Disable invalid `__start/__stop` reference on NVPTX (#99381)

Summary:
The logic for this `__is_function_overridden` check requires accessing a
runtime array normally created by the linker.

[libcxx] Disable invalid `__start/__stop` reference on NVPTX (#99381)

Summary:
The logic for this `__is_function_overridden` check requires accessing a
runtime array normally created by the linker. The NVPTX target is an
`__ELF__` target, however it does not support emitting the
`__start/__stop` symbols for C-identifier named sections. This needs to
be disabled explicitly so that the user can compile this with anything.

show more ...

[libc++][libc++abi] Minor follow-up changes after ptrauth upstreaming (#87481)

This patch applies the comments provided on #84573. This is done as a
separate PR to avoid merge conflicts with downst

[libc++][libc++abi] Minor follow-up changes after ptrauth upstreaming (#87481)

This patch applies the comments provided on #84573. This is done as a
separate PR to avoid merge conflicts with downstreams that already had
ptrauth support.

show more ...

[libc++][NFC] Remove outdated comment about overridable_function being in libcxx/include

[libc++] Upstream ptrauth support in libc++ and libc++abi (#84573)

This is an exact upstreaming of the downstream diff. Minor
simplifications can be made in the future but upstreaming as-is will
m

[libc++] Upstream ptrauth support in libc++ and libc++abi (#84573)

This is an exact upstreaming of the downstream diff. Minor
simplifications can be made in the future but upstreaming as-is will
make it easier for us to deal with downstream merge conflicts.

Partially fixes #83805

show more ...

[libc++] Fix the behavior of throwing `operator new` under -fno-exceptions (#69498)

In D144319, Clang tried to land a change that would cause some functions
that are not supposed to return nullptr

[libc++] Fix the behavior of throwing `operator new` under -fno-exceptions (#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

show more ...