| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) 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 (cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c) | 1 年前 | |
[libc++] Always keep libc++abi re-exports up-to-date (#79012) 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 | 2 年前 | |
[libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) 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 (cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c) | 1 年前 | |
[libc++abi] Fix test failures with GCC 14 (#95759) 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. | 2 年前 | |
[libc++] Always keep libc++abi re-exports up-to-date (#79012) 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 | 2 年前 | |
[libcxxabi] Use an explicit list to export symbols from the dylib Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D63345 llvm-svn: 364586 | 6 年前 | |
[libcxxabi] Use an explicit list to export symbols from the dylib Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D63345 llvm-svn: 364586 | 6 年前 | |
[libc++] Always keep libc++abi re-exports up-to-date (#79012) 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 | 2 年前 | |
[libc++] Always keep libc++abi re-exports up-to-date (#79012) 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 | 2 年前 | |
[libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) 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 (cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c) | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 |