マクロ定義

dbx はマクロ定義を 2 つの方法で認識できます。

• デバッグ情報のデフォルトの DWARF 形式を使用する場合は、-g3 オプションでコンパイルするときにコンパイラによって定義が提供されます。コンパイル時に -xdebugformat=stabs オプションを指定すると、それらは提供されません。

• dbx は、ソースファイルとそのインクルードファイルのスキミングによって定義を再作成できます。正確に再作成できるかどうかは、元のソースファイルとインクルードファイルへのアクセスによって決まります。また、使用されたコンパイラのパス名が使用可能かどうか、および、-D や -I などのコンパイラオプションにも依存します。この情報は Oracle Solaris Studio コンパイラから DWARF 形式とスタブ形式の両方で使用できますが、GNU からは使用できません。スキミングを確実に成功させる方法については、「スキミングエラー」および 「pathmap コマンドを使用したスキミングの改善」を参照してください。

マクロ定義を認識する 2 つの方法のどちらを dbx で使用するかは、dbx 環境変数 macro_source (第 3 章dbx のカスタマイズの表 3-1 を参照) で制御されます。

dbx で使用する方法を選択するときに、考慮すべき要因がいくつかあります。

コンパイラとコンパイラオプション

1 つの要因は、コードを構築するために使用したコンパイラとコンパイラオプションによって決まる、使用可能な情報の種類です。次の表に、コンパイラとデバッグ情報オプションに応じて選択できる方法を示します。

表 C-1 さまざまな構築オプションで使用できるマクロ定義方法

機能におけるかね合い

考慮すべきもう 1 つの要因は、選択する方法によって決まる、機能におけるかね合いです。

• 実行可能ファイルのサイズ。スキミング方法の主な利点は、-g オプションでのコンパイルによって生成されたより小さい実行可能ファイルで機能するため、-g3 オプションでコンパイルする必要がないことです。

• デバッグの形式。スキミングは DWARF とスタブの両方で機能します。-g3 オプションでコンパイルしてコンパイラから定義を取得する場合は、DWARF でのみ機能します。

• 速度。スキミングでは、dbx でまだデバッグ情報が読み取られていないモジュールの式が最初に評価されるときに、最大 1 秒かかります。

• 正確さ。-g3 オプションでコンパイルするときにコンパイラによって提供される情報は、スキミングによって提供される情報よりも正確で安定しています。

• 使用できる構築環境。スキミングでは、デバッグ中にコンパイラ、ソースコードファイル、およびインクルードファイルが使用可能でなければなりません。dbx はこれらの項目が古くなっているかどうかを確認しないため、これらが変更される可能性が高いときは、正確さが低下することがあり、スキミングを利用するよりも -g3 オプションでコンパイルする方がよい場合があります。

• コードがコンパイルされたシステムとは異なるシステムでのデバッグ。システム A でコードをコンパイルし、システム B でデバッグする場合、dbx は NFS を使用し、一部に pathmap コマンドを利用して (「pathmap コマンドを使用したスキミングの改善」を参照)、システム A 上のファイルにアクセスします。

  pathmap コマンドは、スキミング中のファイルアクセスを容易にするためにも役立ちます。プログラムのソースファイルとインクルードファイルに対して役立ちます。ただし、システムインクルードファイルに対しては役立たないことがあります。これは、/usr/include は通常 NFS を介して使用できず、構築システムではなくデバッグシステムの /usr/include からマクロ定義が抽出されるためです。

  システムインクルードファイル間の不整合の可能性を認識して許容するか、-g3 オプションでコンパイルするかを選択できます。

制限事項

• Fortran コンパイラは cpp(1) 関数または fpp(1) 関数を通してマクロをサポートしますが、dbx では Fortran のマクロ展開はサポートされていません。

• dbx では、-g3 オプションおよび -xdebugformat=stabs オプションでのコンパイルによって生成されたマクロ情報は無視されます。

• スキミングは、-g オプションおよび -xdebugformat=stabs オプションでコンパイルされたコードで機能します。