ソフトウェアの修正事項

ここでは、Oracle Solaris Studio 12.2 dbx のこのリリースで解決された問題について説明します。

1. tracei ステップを行っているときに dbx の実行を停止できない

   Solaris プラットフォームで tracei ステップを実行しているときに、Ctrl-C (^C) キーを押して dbx を停止できませんでした。これは実際には Solaris OS のバグですが、問題を回避するように dbx が変更されました。

2. 計装されている debuglog uttsc バイナリにステップインできない

   dbx は、字句ブロック内の C++ 名前空間の別名を正しく処理していませんでした。これにより、明示的に計装されたバイナリに dbx がステップインできない問題が発生していました。

3. Purify を指定して計装されているマルチスレッドプログラムの dbx でスレッド関連のコマンドを使用できない

   Purify を指定すると、計装されるすべての共有ライブラリの名前に接尾辞が追加されます。たとえば、libc.so.1 は libc.so.1_pure_p3_c0_1005282029_510_32 になります。dbx は libc.so.1 の存在を基にして決定を行っており、読み込まれていませんでした。dbx は _pure* 接尾辞を認識するようになりました。

4. 特定の GCC 4.x. sybx を復号化できない dbx が SLES 10.2 のコアファイルからプログラム名を抽出できない

   SuSE Linux Enterprise Server 10.2 システムでは、新しい Linux システムのコアファイルに 2 つの note セクションが含まれていて、2 番目のセクションは空であるため、dbx はコアファイルからプログラムを抽出できませんでした。dbx は 1 番目のセクションから名前を取得するようになります。

5. dbx が gcc コードでコンストラクタのコピーを検索する

   gcc は 1 つのメンバーに対して複数のエントリを生成する場合があり、それが DWARF デバッグの pubnames セクション、プロトタイプ、および抽象インスタンスに含まれていました。dbx は、プロトタイプエントリのインスタンスを検出して処理すると、エントリを削除する必要がありました。

6. dbx が SLES 10.2 のコアファイルからプログラム名を抽出できない

   SuSE Linux Enterprise Server 10.2 システムでは、新しい Linux システムのコアファイルに 2 つの note セクションが含まれていて、2 番目のセクションは空であるため、dbx はコアファイルからプログラムを抽出できませんでした。dbx は 1 番目のセクションから名前を取得するようになります。

7. dbx が変数の出力で SIGSEGV を取得する

   実行可能ファイルが -g オプションを指定してコンパイルされていないオブジェクトファイル (.o) から構築されていて、dbx が変数を評価するためにそのようなオブジェクトファイルの 1 つをインポートする必要がある場合、dbx がこの条件を検査していないためにインポートが失敗する場合がありました。

8. dbx — core segv if が有効ではない

   dbx は長さがゼロのコアファイルの可能性を検査していず、それを正しく処理していませんでした。

9. 「メモリー」ウィンドウおよび「逆アセンブル」ウィンドウによって IDE で dbx がクラッシュする場合がある

   「メモリー」ウィンドウまたは「逆アセンブル」ウィンドウの表示中に IDE のデバッグセッションを終了し、そのあとでセッションを再開した場合、どちらかのウィンドウを前面にすると基になっている dbx がクラッシュしていました。