在 32 位环境中调用 __tls_get_addr 是否危险？答案

【问题标题】：Is it dangerous, that ___tls_get_addr called in 32bit environment?在 32 位环境中调用 __tls_get_addr 是否危险？
【发布时间】：2020-09-23 19:41:27
【问题描述】：

我们有 x86_64 系统，但所有库和应用程序都是为 i386 构建的，我们在 i386 模式下运行它们。 gdb（还有 ltrace）告诉我们，使用了 ___tls_get_addr，据我所知，它是为 x86_64 设计的（___tls_get_addr gnu），而且我们还有 glibc 版本 2.19-18（看起来问题仅在 glibc- 2.24）。从以 i386 模式运行的应用程序调用 ___tls_get_addr 是否危险？如果这是一个问题，我们如何解决这个问题？提前致谢。

【问题讨论】：

作为一般的经验法则，对于 C++ 程序，应用程序的所有部分，包括它所链接的库，都应该使用相同构建i> 相同架构的精确编译器。否则，无法保证行为正确。
@JesperJuhl 看起来我们有 x86_64 系统，它构建 i386 包，glibc 版本 2.23 构建了 gcc 5.4，我们有 2.19 构建了 4.8.4...
好的，然后在相同的架构上使用相同的编译器重新编译你的东西。问题解决了。
@JesperJuhl 这可能是个好主意，但不能简单地实现。操作系统差异的原因。好吧，谢谢你的意见，无论如何我们都会尝试。
您可以将开发人员版本的编译器反向移植到运行相同的旧操作系统，例如，我们最近必须获得 gcc 的开发版本才能在 redhad 6（旧版）上构建我们的软件因为redhat 6上的默认编译器不支持我们使用的一些特性

标签： c++ c glibc libstdc++

【解决方案1】：

您引用的 GCC bug in __tls_get_addr stack alignment 特定于 x86-64。它在 i386 上不存在。我假设您在问题中交换了 i386 和 x86-64。

一般来说，分发工具链是一致的并且经过良好测试。如果您使用系统编译器编译程序并使用系统 glibc 版本，__tls_get_addr 将按预期工作，即使 GCC 错误尚未修复。只有当有缺陷的程序使用恰好使用向量指令的malloc 运行时，才会出现该错误。使用 glibc 的 malloc，这只发生在 GCC 7 或更高版本中。一旦 Fedora 开始使用 GCC 7 作为系统编译器，glibc 中的 GCC 错误的不完整解决方法就被发现了，并且在上游实现了更完整的解决方法（并集成到 Fedora 中）。在 GCC 7 切换之前，有缺陷的应用程序运行良好。

Some distributions have backported the fix 因为它们支持多个编译器和malloc 实现。最后，这是一个分发集成问题，所以如果您有疑问，您需要咨询您的分发支持。

___tls_get_addr（三个下划线）只是一个内部实现细节。它对 glibc 2.20 及更早版本中的某些调试工具可见，因为它不是隐藏符号。在 glibc 2.21 及更高版本中，它被隐藏（在 i386 上），ltrace 和类似工具将不再报告它。这只是轻微的性能优化，不会影响功能。

【讨论】：