mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-18 18:36:42 +00:00
677e8cd6ff
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
14 lines
684 B
Plaintext
14 lines
684 B
Plaintext
# These symbols are not re-exported from libc++ because providing a definition in libc++ causes
|
|
# issues with some clients when backdeploying.
|
|
|
|
# These symbols are implementation details of libc++abi, but they are referenced from UBSan
|
|
# (which is a total hack). We'll need to figure out how to decouple UBSan from these details
|
|
# before we can stop exporting them from libc++abi.
|
|
__ZTIN10__cxxabiv117__class_type_infoE
|
|
__ZTIN10__cxxabiv120__si_class_type_infoE
|
|
__ZTIN10__cxxabiv121__vmi_class_type_infoE
|
|
|
|
# This symbol is not an implementation detail of libc++abi, but it also causes issues when moving
|
|
# to libc++. This needs further investigation.
|
|
___cxa_rethrow_primary_exception
|