Swift Runtime符号在动态链接库丢失的排查之路 | 小猪的博客

[dreampiggy]

https://dreampiggy.com/2023/12/26/Swift%20Runtime%E5%86%85%E7%BD%AE%E7%AC%A6%E5%8F%B7%E4%B8%A2%E5%A4%B1%E6%8E%92%E6%9F%A5%E4%B9%8B%E8%B7%AF/

声明此篇文章原作者就是我，版权所有。预计未来会刊登在《字节跳动终端技术》 公众号链接： DanceCC是字节Mobile Infra的一套编译工具链的品牌名，基于Swift.org的工具链进行了相关定制，包括调试优化，定制Clang插件特性，自研Pass做包大小和性能优化等等。在先前的文章中均有介绍。 背景近期，有人发来反馈，他们在接入DanceCC的新版本工具链时，在调整了一些库的工具链选择

[dreampiggy]

如果对Swift Compiler Toolchain，比如行为对齐，优化LLVM Pass实现等有感兴趣的同学，欢迎通过我的社交媒体如Twitter/GitHub/Email交流

[ChengzhiHuang]

今天精读了一下，所获颇多。期间有一些小困惑如下：

1

可以分析出大概的问题，发生在，该符号要么应该直接以t或者T（即Global或者Local）符号存在于AppStorageCore；要么应该其递归加载的EEAtomic/LKCommonsLogging以T（即Global）符号暴露出来

这里的 t 与 T 对应的符号有反过来了，是否可以更正表达为：

该符号要么应该直接以t（Local）或者T（Global）符号存在于AppStorageCore；

2

跳板会检查是否当前运行的host环境需要打补丁：

我没有细读 swift 的源码，按我对截图部分代码的理解，其实是对每一个需要 override 的 function 都宏展开了一个新的函数指针，然后根据函数指针是否为空，为空就是不需要 override，不为空就是需要 override（也就是打补丁）。

那 跳板 其实就是下一张图里的 判断是否有对应的 sectionPtr ，有就是需要 override ，没有就不需要。这就让我有一个困惑，那岂不是只要需要展开的函数，都只需要判断 Section 是否存在，那是如何准确匹配需要额外的补丁的？因为这样看，所有展开的都会走到有补丁的逻辑？那就是其实每个 补丁 都包含 所有 Runtime API 的新的实现，因此只要有需要决策的，就一定会走 Section 里的新的实现？

那如果需要 libswiftCompatibility50.a + libswiftCompatibility51.a ，这两个补丁里是不会有同样的函数吗？不然不就是还会有到底拿 50 还是 51 的问题？

Nit：这一块其实因为本身宏展开读起来会有些费劲，其实可以考虑在最后把代码合并到一起，用一些更显著得方式（例如拉个红箭头）让读者知道这个宏展开之后是跳到哪个函数中。这个部分我大致阅读了 20 min（

3

typo

这个宏辉标记在所有Swift的Runtime API上，因此在编译时刻都确保支持了后续版本的补丁替换，达成了“向后兼容”

to

这个宏会标记在所有Swift的Runtime API上，因此在编译时刻都确保支持了后续版本的补丁替换，达成了“向后兼容”

[dreampiggy]

已经修改。