Swift Runtime符号在动态链接库丢失的排查之路 | 小猪的博客
Opened this issue · 3 comments
声明此篇文章原作者就是我，版权所有。预计未来会刊登在《字节跳动终端技术》 公众号链接： DanceCC是字节Mobile Infra的一套编译工具链的品牌名，基于Swift.org的工具链进行了相关定制，包括调试优化，定制Clang插件特性，自研Pass做包大小和性能优化等等。在先前的文章中均有介绍。 背景近期，有人发来反馈，他们在接入DanceCC的新版本工具链时，在调整了一些库的工具链选择
如果对Swift Compiler Toolchain，比如行为对齐，优化LLVM Pass实现等有感兴趣的同学，欢迎通过我的社交媒体如Twitter/GitHub/Email交流
今天精读了一下，所获颇多。期间有一些小困惑如下：
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上，因此在编译时刻都确保支持了后续版本的补丁替换，达成了“向后兼容”
已经修改。