5.4.10. コンパイラーおよび開発ツール
dlopen
の失敗時に、未配置で初期化されていない共有オブジェクトが失敗することがなくなりました。
以前は、dlopen
呼び出しに失敗すると、glibc
動的リンカーは、エラー報告前に NODELETE
マークの付いた共有オブジェクトを削除しませんでした。そのため、未配置で初期化されていない共有オブジェクトがプロセスイメージに残され、最終的にはアサーションの失敗またはクラッシュにつながっていました。今回の更新で、動的ローダーは dlopen
失敗時に、保留中の NODELETE
状態を使用して共有オブジェクトを削除した後で、それらを永続的に NODELETE
としてマークするようになりました。その結果、再配置されていないオブジェクトがプロセスに取り残されることはありません。また、ELF コンストラクターおよびデストラクターの実行中に遅延結合が失敗すると、プロセスが終了するようになりました。
64 ビット ARM アーキテクチャーの Advanced SIMD 関数は遅延解決時に誤ってコンパイルしなくなりました。
以前のリリースでは、Advanced SIMD の新しいベクトルプロシージャーコール標準 (PCS) で、Advanced SIMD 機能の遅延解決時に、特定の呼出先退避レジスターが正しく保存、復元されませんでした。そのため、ランタイム時にバイナリーが誤作動する可能性がありました。今回の更新では、シンボルテーブルの Advanced SIMD と SVE ベクトル関数は .variant_pcs
とマーク付されたので、動的なリンカーはこのような関数を初期にバインドするようになります。
sudo
ラッパースクリプトはオプションを解析するようになりました。
以前のリリースでは、/opt/redhat/devtoolset*/root/usr/bin/sudo
ラッパースクリプトは 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
ファイルに正しく追加されるようになりました。
内部障害が発生しても mtrace
がハングしなくなりました。
以前のリリースでは、mtrace
ツールの実装に不具合が原因で、メモリートレースがハングする可能性がありました。この問題を修正するために、mtrace
メモリートレースの実装が堅牢化され、内部障害の発生時にもハングが発生しなくなりました。その結果、mtrace
を呼び出しても、ハングしなくなり、制限時間内に完了するようになりました。
fork
関数は pthread_atfork
を使用すると発生する特定のデッドロックを回避するようになりました。
以前のリリースは、プログラムが atfork
ハンドラーを登録し、非同期署名ハンドラーから fork
を呼び出すと、内部実装依存ロックの不具合により、プログラムがフリーズする可能性がありました。今回の更新で、フォーク
とその atfork
ハンドラーの実装を調整し、シングルスレッドプログラムでデッドロックを回避できるようになりました。
strstr
は、省略されたパターンに対して、正しい一致内容を返すようになりました。
一部の IBM Z プラットフォーム (z15、以前は arch13) では、strstr
関数は、ページの境界をまたぐ検索パターンを処理する場合に CPU レジスターが適切に更新されませんでした。これにより、strstr
は誤った一致内容を返していました。今回の更新でこの問題が修正され、上記のシナリオで strstr
が期待どおりに動作するようになりました。
glibc
における C.UTF-8 ロケールソースの省略表現が修正されました。
以前は、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
) パスワードプロバイダーを参照する場合は、最初に setpwent()
を 1 度のみ呼び出すことなく、getpwent()
関数を使用してデータを要求できます。endpwent()
関数を呼び出すとき、最初に setpwent()
を呼び出さずに getpwent()
に呼び出しを行うと、glibc
が失敗していました。これは、endpwent()
が新しいクエリーを許可するように内部をリセットできなかったためです。今回の更新でこの問題が修正されています。その結果、endpwent()
で 1 つのクエリーを終了すると、setpwent()
を呼び出さなくても、getpwent()
への呼び出しがさらに新しいクエリーを開始します。
ltrace
は、強化されたバイナリーでのシステムコールを追跡できるようになりました。
以前のリリースでは、ltrace
を使用して、AMD および Intel 64 ビットアーキテクチャー上のシステムバイナリーなど、特定の強化されたバイナリーで結果が生成されませんでした。今回の更新で、ltrace
が、強化されたバイナリーでのシステムコールを追跡できるようになりました。
(BZ#1655368)
Intel の JCC の不具合により、GCC コンパイラーでパフォーマンスが大幅に低下することがなくなりました。
特定の Intel CPU は、マシン命令が誤って実行される原因となるジャンプ条件コード (JCC) バグの影響を受けます。したがって、影響を受けた CPU は、プログラムを適切に実行しない可能性があります。完全な修正には、脆弱な CPU のマイクロコードの更新が含まれており、パフォーマンス低下につながる可能性があります。今回の更新で、パフォーマンスの低下を軽減するのに役立つアセンブラーでの回避策が可能になりました。回避策は、デフォルトでは有効になっていません。
回避策を適用するには、GCC で -Wa,-mbranches-within-32B-boundaries
コマンドラインオプションを使用して、プログラムを再コンパイルします。このコマンドラインオプションで再コンパイルしたプログラムは、JCC の不具合の影響を受けませんが、システムを完全に保護するにはマイクロコードの更新が依然として必要になります。
回避策を適用するとプログラムのサイズが増大します。再コンパイルを行わなかった場合よりは軽微ではあるものの、パフォーマンスがわずかに低下する可能性があることに留意してください。
並行ビルド中に make
の速度が低下することがなくなりました。
以前のバージョンでは、並行ビルドの実行中に、シーケンスの実行を待機すると、make
サブプロセスが一時的に応答しなくなる可能性がありました。その結果、-j
の値が高いビルドは遅延するか、効果的な -j
の値が低いで実行されました。今回の更新では、make
のジョブ制御ロジックがブロックされなくなりました。その結果、-j
の値が高いビルドが完全な -j
の速度で実行されます。
ltrace
ツールが関数呼び出しを正しく報告するようになりました。
すべての RHEL コンポーネントに適用されるバイナリー強化を改善したことが原因で、以前は、ltrace
ツールで RHEL コンポーネントからのバイナリーファイルの関数呼び出しを検出できませんでした。これにより、ltrace
の出力では、このようなバイナリーファイルで使用されたときに検出される呼び出しが報告されず、空になっていました。今回の更新で、ltrace
が関数呼び出しを処理する方法が修正され、上記の問題が発生しなくなりました。
(BZ#1618748)