GCC 5.3中的新选项:-fno-semantic-interposition

Dev*_*ark 9 c++ gcc gcc5

GCC 5.3增加了一个新选项: -fno-semantic-interposition

新的-fno-semantic-interposition选项可用于提高共享库的代码质量,其中不允许插入导出的符号.

这听起来像是对C++项目有用的东西,其中插入不能用于任何原因,但延迟是一个问题.

但是,描述相当模糊.有人能够澄清这个选项是如何工作的吗?

yug*_*ugr 10

-fno-semantic-interposition 可以显着提高共享库中代码的性能,但在某些情况下可能会改变语义。

默认情况下,GCC 尊重 ELF 符号插入语义。简而言之,任何导出的库函数(即,如果使用默认编译器标志编译的任何库函数)都可以在运行时通过LD_PRELOAD或简单地由另一个共享库中的同名函数替换,该函数恰好由动态链接器更早加载。这会阻止编译器进行大量有用的分析和优化(最显着的是内联和克隆),因为它们可能会中断插入。

-fno-semantic-interposition 允许编译器忽略潜在的插入并更积极地优化。

正如我所说,使用时有一些注意事项-fno-semantic-interposition

  • 它可能会改变你的程序的行为(当它实际上依赖于插入时,有时你没有意识到这一点)
  • 它只与共享库相关(不是可执行文件)
  • 如果您已经对库进行了适当的优化(即使用 编译-fvisibility=hidden并显式注释所有导出的符号__attribute__((visibility("default")))),它就没那么有用了

第一项防止广泛部署fno-semantic-interposition. 例如,据我所知,没有Linux 发行版大规模使用它(顺便说一句,这将是一个很棒的项目)。

顺便说一下,Clang 编译器-fno-semantic-interposition默认启用,大概是为了性能。它们有一个反向-fsemantic-interposition标志来启用 ELF 插入语义。

  • @curiousguy 是的,而且它已被证明会导致错误(有关详细信息,请参阅 [Flameeyes 博客文章关于符号冲突](https://flameeyes.blog/tag/collisions/))。现在推荐的编程实践是通过 `-fvisibility=hidden` 减少导出的符号。不幸的是,这并没有得到严格遵守(我开发了一个[检测虚假符号导出的工具](https://github.com/yugr/ShlibVisibilityChecker),但社区对此并没有太大兴趣)。 (2认同)