在 32 位环境中调用 ___tls_get_addr 是否危险？
Is it dangerous, that ___tls_get_addr called in 32bit environment?
我们有 x86_64 系统，但所有库和应用程序都是为 i386 构建的，我们 运行 它们处于 i386 模式。
gdb（还有 ltrace）告诉我们，使用了 ___tls_get_addr，据我所知，它是为 x86_64 设计的（___tls_get_addr gnu），我们还有 glibc 版本 2.19-18 （看起来问题仅在 glibc-2.24 中得到修复）。在 i386 模式下从应用程序 运行ning 调用 ___tls_get_addr 是否危险？如果它是一个问题，我们如何解决这个问题？提前致谢。
您引用的 GCC bug in __tls_get_addr stack alignment 特定于 x86-64。它在 i386 上不存在。我假设您在问题中交换了 i386 和 x86-64。
总的来说，分发工具链是一致的 well-tested。如果您使用系统编译器编译您的程序并使用系统 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 和类似工具将不再报告它。这只是一个小的性能优化，它不影响功能。
我们有 x86_64 系统，但所有库和应用程序都是为 i386 构建的，我们 运行 它们处于 i386 模式。 gdb（还有 ltrace）告诉我们，使用了 ___tls_get_addr，据我所知，它是为 x86_64 设计的（___tls_get_addr gnu），我们还有 glibc 版本 2.19-18 （看起来问题仅在 glibc-2.24 中得到修复）。在 i386 模式下从应用程序 运行ning 调用 ___tls_get_addr 是否危险？如果它是一个问题，我们如何解决这个问题？提前致谢。
您引用的 GCC bug in __tls_get_addr stack alignment 特定于 x86-64。它在 i386 上不存在。我假设您在问题中交换了 i386 和 x86-64。
总的来说，分发工具链是一致的 well-tested。如果您使用系统编译器编译您的程序并使用系统 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 和类似工具将不再报告它。这只是一个小的性能优化，它不影响功能。