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
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
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
Summary:
Those functions started being mistakenly exported from the libc++abi
shared library after commit r344152 in 2018. Removing these symbols is
technically an ABI break. However, they are not part of the C++ ABI,
they haven't ever been re-exported from libc++, and they are not
declared in any public header, so it's very unlikely that calls to
these functions exist out there. Also, the functions have reserved
names, so any impacted user would have to have tried really hard
being broken by this removal.
Note that avoiding this kind of problem is exactly why we're now
controlling exported symbols explicitly with a textual list.
Also note that applying the hidden visibility attribute is necessary
because the list of exported symbols is only used on Apple platforms
for the time being.
Reviewers: phosek, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68357
llvm-svn: 373602
