dbx はマクロ定義を 2 つの方法で認識できます。
デバッグ情報のデフォルトの DWARF 形式を使用する場合は、–g3 オプションでコンパイルするときにコンパイラによって定義が提供されます。ただし、コンパイル時に –xdebugformat=stabs オプションを指定した場合は提供されません。
dbx は、ソースファイルとそのインクルードファイルのスキミングを行うことによって定義を再作成できます。正確な再作成は、元のソースとインクルードファイルへのアクセスに依存しています。また、使用されているコンパイラがパス名を使用できるかどうか、および –D や –I などのコンパイラオプションにも依存します。この情報は Oracle Developer Studio コンパイラから DWARF 形式とスタブ形式の両方で使用できますが、GNU コンパイラからは使用できません。スキミングを確実に成功させる方法については、スキミングエラーおよび pathmap コマンドを使用したスキミングの改善を参照してください。
dbxenv 変数 macro_source (dbx のカスタマイズの表 1 を参照) は、マクロ定義を認識するために dbx で 2 つのメソッドのうちのいずれを使用するかを制御します。
dbx で使用する方法を選択するときに、考慮すべき要因がいくつかあります。
マクロ定義方法を選択する場合の 1 つの要因は、コードを構築するために使用したコンパイラやコンパイラオプションによって異なるさまざまな種類の情報が使用可能かどうかです。次の表に、コンパイラとデバッグ情報オプションに応じて選択できる方法を示します。
|
マクロ定義方法を選択する場合に考慮すべきもう 1 つの要因は、どの方法を選択するかによって異なる、機能におけるかね合いです。
実行可能ファイルのサイズ。スキミング方法の主な利点は、–g オプションでのコンパイルによって生成されたより小さい実行可能ファイルで機能するため、–g3 オプションでコンパイルする必要がないことです。
デバッグの形式。スキミングは DWARF とスタブの両方で機能します。–g3 オプションでコンパイルしてコンパイラから定義を取得する場合は、DWARF でのみ機能します。
速度。スキミングでは、dbx でまだデバッグ情報が読み取られていないモジュールの式が最初に評価されるときに、最大 1 秒かかります。
正確性。–g3 オプションでコンパイルするときにコンパイラによって提供される情報は、スキミングによって提供される情報よりも正確で安定しています。
構築環境が使用可能かどうか。スキミングでは、デバッグ中にコンパイラ、ソースコードファイル、およびインクルードファイルが使用可能である必要があります。dbx は、これらの項目が古くなっているかどうかをチェックしないため、変更されている可能性が高い場合は、正確性が低下することがあり、スキミングに依存するよりも –g3 オプションでのコンパイルの方が適切であることがあります。
コードがコンパイルされたシステムとは異なるシステムでのデバッグ。システム A でコードをコンパイルし、それをシステム B でデバッグしている場合、dbx は、pathmap コマンドをある程度利用しながら NFS を使用してシステム A 上のファイルにアクセスします。
pathmap コマンドはまた、スキミング中のファイルアクセスを容易にするためにも役立ちます。これは、プログラムのソースファイルとインクルードファイルに対しては機能しますが、/usr/include が通常 NFS 経由では使用できないため、システムのインクルードファイルに対しては機能しない可能性があります。そのため、マクロ定義は構築システムではなく、デバッグシステム上の /usr/include から抽出されます。
システムインクルードファイル間の不整合の可能性を認識して許容するか、–g3 オプションでコンパイルするかを選択できます。
Fortran コンパイラは cpp(1) 関数または fpp(1) 関数を通してマクロをサポートしますが、dbx では Fortran のマクロ展開はサポートされていません。
dbx では、–g3 オプションおよび –xdebugformat=stabs オプションでのコンパイルによって生成されたマクロ情報は無視されます。
スタブのインデックスの詳細については、install-dir/solarisstudio12.4/READMEs/stabs.pdf のパスにあるスタブのインタフェースに関するガイドを参照してください。
スキミングは、–g オプションおよび –xdebugformat=stabs オプションでコンパイルされたコードで機能します。