デフォルトでは、選択された式は、評価される前にマクロ展開されます。これには、print、display、watch の各コマンドで指定する式、stop、trace、when の各コマンドの –if オプション、および $[] 構造も含まれます。マクロ展開はまた、IDE や dbxtool でのバルーン評価とウォッチポイントにも適用されます。
マクロ展開は、assign コマンド内の変数と式の両方に適用されます。
call コマンドでは、マクロ展開は呼び出される関数の名前だけでなく、渡されるパラメータにも適用されます。
macro コマンドは任意の式とマクロを受け取り、そのマクロを展開します。 例:
(dbx) macro D(1, 2)
Expansion of: D(1, 2)
is: d(1,2)whatis コマンドにマクロを指定すると、そのマクロの定義が表示されます。 例:
(dbx) whatis B
#define B(x) b(x)which コマンドにマクロを指定すると、スコープ内で現在アクティブなマクロがどこで定義されているかが表示されます。 例:
(dbx) which B2
`a.out`macro_wh.c`B2 # defined at defs2.h:3
# included from defs1.h:3
# included from macro_wh.c:23whereis コマンドにマクロを指定すると、そのマクロが定義されているすべての場所が表示されます。 リストは、dbx がすでにデバッグ情報を読み取ったモジュールに限られます。例:
(dbx) whereis U
macro: U # defined at macro_wh.c:21
macro: U # undefined at defs1.h:5dbxenv 変数 macro_expand は、これらのコマンドによってマクロが展開されるかどうかを制御します。 デフォルトでは on に設定されます。
通常、dbx コマンドの +m オプションにより、コマンドでのマクロ展開は省略されます。–m オプションは、dbxenv 変数 macro_expand が off に設定されている場合でも、マクロ展開を強制します。1 つの例外は、$[] 構造内の –m オプションです。その場合は、–m マクロが展開されるだけで、評価は実行されません。この例外により、シェルスクリプトでのマクロ展開が容易になります。
dbx はマクロ定義を 2 つの方法で認識できます。
デバッグ情報のデフォルトの DWARF 形式を使用する場合は、–g3 オプションでコンパイルするときにコンパイラによって定義が提供されます。ただし、コンパイル時に –xdebugformat=stabs オプションを指定した場合は提供されません。
dbx は、ソースファイルとそのインクルードファイルのスキミングを行うことによって定義を再作成できます。正確な再作成は、元のソースとインクルードファイルへのアクセスに依存しています。また、使用されているコンパイラがパス名を使用できるかどうか、および –D や –I などのコンパイラオプションにも依存します。この情報は Oracle Solaris Studio コンパイラから DWARF 形式とスタブ形式の両方で使用できますが、GNU からは使用できません。スキミングを確実に成功させる方法については、スキミングエラーおよび pathmap コマンドを使用したスキミングの改善を参照してください。
dbxenv 変数 macro_source (Chapter 3, dbx のカスタマイズのTable 3–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 オプションでコンパイルされたコードで機能します。
コードを –g3 オプションでコンパイルせず、かつ macro_source dbxenv 変数が skim_unless_compiler または skim に設定されている場合は、マクロスキミングに依存しています。
モジュールのスキミングを正常に実行するには、次の条件が成立する必要があります。
このモジュールは、Oracle Solaris Studio コンパイラで –g オプションを使用してコンパイルされている必要があります。
モジュールのコンパイルに使用されたコンパイラに dbx からアクセスできることが必要です。
このモジュールのソースファイルに、dbx からアクセスできる必要があります。
このモジュールのソースコードによってインクルードされたファイルが使用可能である必要があります。つまり、このモジュールがコンパイルされたときに –I オプションに指定されたパスに、dbx からアクセスできる必要があります。
ソースコードは字句的に正常でなければなりません。たとえば、終了していないコメント文字列が含まれていたり、#endif が欠けていたりしてはいけません。
ソースコードやインクルードファイルに dbx からアクセスできない場合は、pathmap コマンドを使用してそれらをアクセス可能にすることができます。
コンパイル後にソースファイルを移動した場合、あるマシンで構築したあとに別のマシンでデバッグする場合、または ソースファイルおよびオブジェクトファイルの検索で説明されているその他の状況のいずれかに当てはまる場合は、マクロスキミングでスキミング対象のファイル内にインクルードファイルが見つからないことがあります。この解決方法として、ファイルが見つからないその他の場合と同様に、pathmap コマンドを使用してマクロスキマーでインクルードディレクトリを見つけやすくします。 たとえば、オプション –I/export/home/proj1/include でコンパイルし、コードに文 #include "module1/api.h" があると仮定します。その後、proj1 から proj2 に名前を変更した場合、次の pathmap コマンドにより、マクロスキマーはファイルを見つけやすくなります。
pathmap /export/home/proj1 /export/home/proj2
パスマップは、元のコードのコンパイルに使用されたコンパイラには適用されません。
マクロの作業以外では、ファイルが見つからないときに pathmap コマンドを使用してパスマップを変更すると変更はただちに有効になりますが、マクロの作業では、パスマップを有効にするにはアプリケーションを再度読み込む必要があります。
あるマシンで構築し別のマシンでデバッグする場合に、pathmap コマンドによって dbx は正しいファイルを見つけやすくなります。ただし、/usr/include/stdio.h などのシステムインクルードファイルは通常は構築マシンからエクスポートされないため、マクロスキマーではデバッグマシン上のファイルが使用される可能性があります。場合によっては、デバッグマシン上でステムインクルードファイルを使用できないことがあります。また、システム固有のマクロやシステムに依存するマクロの値が、デバッグマシン上と構築マシン上とでは同じでない可能性もあります。
pathmap コマンドでスキミングの問題が解決されない場合は、コードを –g3 オプションでコンパイルし、macro_source dbxenv 変数を skim_unless_compiler または compiler に設定することを検討してください。