5.4.10. 编译器和开发工具

如果 dlopen 失败，unrelocated 和未初始化共享对象不再会导致失败

在以前的版本中，如果 dlopen 调用失败，glibc 动态链接程序不会在报告错误前删除带有 NODELETE 标记的共享对象。因此，未重新定位和未初始化的共享对象会保留在进程镜像中，最终会导致断言失败或崩溃。在这个版本中，动态加载器使用待处理的 NODELETE 状态在 dlopen 失败时删除共享对象，然后将其标记为 NODELETE。因此，进程不会留下任何未重新定位的对象。另外，当 ELF 构造器和 destructors 运行时 lazy 绑定失败现在终止该进程。

64 位 ARM 架构中的高级 SIMD 功能在临时解决方案后不再复杂

在以前的版本中，当延迟解析高级 SIMD 功能时，用于高级 SIMD 的新向量标准(PCS)无法正确保存和恢复某些调用者保存的寄存器。因此，二进制文件可能会在运行时发生错误。在这个版本中，符号表中的 Advanced SIMD 和 SVE 向量函数标记为 .variant_pcs，因此动态链接器会早期绑定这些函数。

sudo wrapper 脚本现在解析选项

在以前的版本中，/opt/redhat/devtoolset*/root/usr/bin/sudo wrapper 脚本无法正确解析 sudo 选项。因此，无法执行一些 sudo 选项（如 sudo -i）。在这个版本中，可以正确地解析更多 sudo 选项，因此 sudo 打包程序脚本的工作方式更像 /usr/bin/sudo。

修复了 glibc 中的 TLS 变量对齐的问题

在以前的版本中，在某些情况下，一致的线程本地存储(TLS)数据可能会实例化而无需预期的对齐。在这个版本中，POSIX Thread Library libpthread 已被改进，以确保在任何条件下都正确一致。因此，为所有带有正确对齐的线程正确实例化了一致的 TLS 数据。

EINTR 或 EAGAIN 错误后重复的 pututxline 调用不再破坏 utmp 文件

当 pututxline 函数试图获取锁定且不成功时，该函数会返回 EINTR 或 EAGAIN 错误代码。在以前的版本中，如果立即调用 pututxline 并被管理来获取锁定，则它没有在 utmp 文件中使用已分配的匹配插槽，而是添加另一个条目。因此，这些未使用的条目极大地增加了 utmp 文件的大小。在这个版本中解决了这个问题，条目已正确添加到 utmp 文件中。

当发生内部故障时，m trace 不再挂起

在以前的版本中，mtrace 工具实现中的一个缺陷可能会导致内存追踪挂起。为解决这个问题，mtrace 内存追踪实现功能更强，即使在内部故障的情况下也能避免挂起。现在，用户可以调用 mtrace，它不再挂起，从而在有限制的时间里完成。

fork 功能可避免使用 pthread_atfork相关的某些死锁

在以前的版本中，如果程序注册了 in fork 处理程序并从异步信号处理程序调用 fork，则依赖内部实现的锁定中的缺陷可能会导致程序停滞。在这个版本中，对 fork 及其 for fork 处理程序 的实施进行了调整，以避免单线程程序中出现死锁。

strstr 不再为截断模式返回不正确的匹配项

在某些 IBM Z 平台（以前称为 arch13）中，strstr 功能在处理跨页面边界的搜索模式时无法正确更新 CPU 寄存器。因此，strstr 返回了不正确的匹配项。在这个版本中解决了这个问题，strstr 在 上面提到的场景中可以正常工作。

glibc 中的 C.UTF-8 本地源 ellipsis 表达式已被修复

在以前的版本中，C.UTF-8 源区域中的一个缺陷会导致 U+10000 之外的所有 Unicode 代码点都缺乏校验权重。因此，所有超过 U+10000 的代码点均无法按预期互操作。C.UTF-8 源区域设置已被修正，新编译的二进制区域现在对所有 Unicode 代码点具有排序权重。因为这个修复，编译的 C.UTF-8 区域设置会较大 5.3MiB。

当在没有调用 setpwent（）的情况下调用 getpwent（） 时，glibc 不再会失败。

如果您的 /etc/nsswitch.conf 文件指向 Berkeley DB(db)密码提供商，则可以使用 getpwent（） 函数来请求数据，而无需首先调用 setpwent（）。当您调用 endpwent（） 函数时，在没有首先调用 set pwent（）的情况下进一步调用 get pwent（） 会导致 glibc 失败，因为 endpwent（） 无法重置内部来允许新的查询。在这个版本中解决了这个问题。因此，在使用 endpwent（） 结束一个查询后，对 getpwent（） 的其他调用将启动一个新的查询，即使您没有调用 setpwent（）。

ltrace 现在可以跟踪强化二进制文件中的系统调用

在以前的版本中，ltrace 在 AMD 和 Intel 64 位构架中不会在特定强化的二进制文件（如系统二进制文件）中产生任何结果。在这个版本中，lt race 可以跟踪强化的二进制文件中的系统调用。

Intel 的 JCC 漏洞不再会在 GCC 编译器中造成大量性能损失

某些 Intel CPU 受到 Jump Conditional Code(JCC)错误影响，从而导致机器指令被错误地执行。因此，受影响的 CPU 可能无法正确执行程序。完整的修复涉及更新存在安全漏洞 CPU 的 microcode，这可能会导致性能下降。在这个版本中，在 assembler 中启用了一个临时解决方案，可帮助减少性能丢失。默认情况下不启用临时解决方案。

使用并行构建时 不再 减慢

在以前的版本中，当运行并行构建时，当等待其轮流运行时，子 进程可能会临时变得无响应。因此，带有高 -j 值的构建会减慢或以较低有效 -j 值运行。在这个版本中，make 的作业控制逻辑没有阻塞。因此，具有高 -j 值的构建会以全 -j 速度运行。

ltrace 工具现在正确报告功能调用

由于改进了应用于所有 RHEL 组件的二进制强化，ltrace 工具之前无法在 RHEL 组件的二进制文件中检测功能调用。因此，lt race 输出为空，因为它没有报告在此类二进制文件中使用任何检测到的调用。在这个版本中解决了 ltrace 处理函数调用的方式，这可防止上面描述的问题发生。