イベント指定は、stop、stopi、when、wheni、trace、tracei コマンドで、イベントタイプとパラメータを表すために使用します。その書式は、イベントタイプを表すキーワードと省略可能なパラメータで構成されます。 指定子の意味は、一般的にすべてのコマンドで同一です。例外については、コマンドの説明 (「stop コマンド」、「trace コマンド」、「when コマンド」を参照) に記載されています。
ブレークポイントとは、アクションが発生する位置であり、その位置でプログラムは実行を停止します。次に、ブレークポイントイベントに対するイベント仕様を説明します。
関数が入力され、最初の行が実行される直前。先行ログ後の最初の実行可能コードは、実際のブレークポイントの位置として使用されます。この行は、局所変数を初期化する行になることがあります。C++ のコンストラクターの場合、すべてのベースクラスのコンストラクターの実行後に実行されます。-instr 修飾子が使用される場合 (「-instr」参照) は、関数の最初の命令が実行される直前です。function 仕様は、仮パラメータを含むことができるため、多重定義関数名、またはテンプレートインスタンスの指定に役立ちます。たとえば、次のようにします。
stop in mumble(int, float, struct Node *) |
in function と -in function 修飾子とを混同しないでください。
指定の行が実行される直前。filename を指定した場合は、指定ファイルの指定の行が実行される直前。ファイル名には、ソースファイル名またはオブジェクトファイル名を指定します。引用符は不要ですが、ファイル名に特殊文字が含まれる場合は、必要な場合もあります。指定の行がテンプレートコードに含まれる場合、ブレークポイントは、そのテンプレートのすべてのインスタンス上に置かれます。
指定のアドレスの指示が実行される直前。このイベントは stopi コマンド (「stopi コマンド」参照) または -instr イベント修飾子 (「-instr」参照) のみ利用可能です。
function と名付けられたすべての多重定義関数、およびテンプレートインスタンスのすべてに対し、in function と同じ働きをします。
すべてのクラスの function と名付けられたメンバー関数に対し、in function と同じ働きをします。
classname のベースではなく、classname のメンバーであるすべてのメンバー関数に対し、in function と同じ働きをします。-norecurse はデフォルトです。-recurse が指定された場合、基底クラスが含まれます。
object-expression に指定されているアドレスのオブジェクトを呼び出したメンバー関数が呼び出されているとき。stop inobject ox は次のコードとほとんど同じ働きをしますが、inclass と異なり、動的な ox のベースが含まれます。 -recurse はデフォルトです。-norecurse が指定された場合、基底クラスが含まれます。
stop inclass dynamic_type(ox) -if this==ox |
メモリーアドレスへのアクセスまたは変更が必要なイベントのイベント指定の例を示します。
address-expression で指定されたメモリーがアクセスされたとき。
mode はメモリーのアクセス方法を指定します。次の文字 (複数可) で構成されます。
指定したアドレスのメモリーが読み取られたことを示します。
メモリーへの書き込みが実行されたことを示します。
メモリーが実行されたことを示します。
さらに mode には、次のいずれかの文字も指定することができます。
アクセス後にプロセスを停止します (デフォルト)。
アクセス前にプロセスを停止します。
いずれの場合も、プログラムカウンタは副作用アクションの前後で違反している命令をポイントします。「前」と「後」は副作用を指しています。
address-expression は、その評価によりアドレスを生成できる任意の式です。シンボル式を使用すると、監視される領域のサイズが自動的に推定されます。 このサイズは、byte-size-expression を指定することにより、上書されます。シンボルを使用しない、型を持たないアドレス式を使用することもできますが、その場合はサイズを指定する必要があります。たとえば、次のようにします。
stop access w 0x5678, sizeof(Complex) |
access コマンドには、2 つの一致する範囲が重複しない、という制限があります。
access イベント仕様は、modify イベント仕様の代替です。
variable の値は変更されました。change イベントは、次のコードとほとんど同じ働きをします。
when step { if [ $last_value !=$[variable]] then stop else last_value=$[variable] } |
このイベントはシングルステップを使用して実装されます。パフォーマンス速度を上げるには、access イベント (「access mode address-expression [, byte-size-expression ]」参照) を使用します。
最初に variable がチェックされると、変更が検出されない場合でも 1 つのイベントが発生します。この最初のイベントによって variable の最初の値にアクセスできるようになります。あとから検出された variable の値への変更によって別のイベントが発生します。
condition-expression によって示される条件が真と評価されます。condition-expression には任意の式を使用できますが、整数型に評価されなければなりません。cond イベントは、次のコードとほとんど同じ働きをします。
stop step -if conditional_expression
次に、システムイベントに対するイベント指定について説明します。
これらのイベントは、dlopen() または dlclose() の呼び出しが正常終了したあとに発生します。dlopen() または dlclose() の呼び出しにより、複数のライブラリが読み込まれることがあります。これらのライブラリのリストは、事前定義済み変数 $dllist で常に入手できます。$dllist の中の最初のシェルの単語は実際には「+」または「-」で、それぞれライブラリが追加されているか、削除されているかを示します。
lib-path は、該当する共有ライブラリの名前です。これを指定した場合、そのライブラリが読み込まれたり、読み込みが取り消されたりした場合にだけイベントが起動します。その場合、$dlobj にライブラリの名前が格納されます。また、$dllist も利用できます。
lib-path が / で始まる場合は、パス名全体が比較されます。それ以外の場合は、パス名のベースだけが比較されます。
lib-path を指定しない場合、イベントは任意の dl 動作があるときに必ず起動します。$dlobj は空になりますが、$dllist は有効です。
fault イベントは、指定の障害に遭遇したとき、発生します。障害は、アーキテクチャー依存です。dbx に対して知られる次の一連の障害は、proc(4) マニュアルページで定義されています。
障害 |
内容の説明 |
---|---|
FLTILL |
不正命令 |
FLTPRIV |
特権付き命令 |
FLTBPT* |
ブレークポイントトラップ |
FLTTRACE* |
トレーストラップ (ステップ実行) |
FLTACCESS |
メモリーアクセス (境界合わせなど) |
FLTBOUNDS |
メモリー境界 (無効なアドレス) |
FLTIOVF |
整数オーバーフロー |
FLTIZDIV |
整数ゼロ除算 |
FLTPE |
浮動小数点例外 |
FLTSTACK |
修復不可能なスタックフォルト |
FLTPAGE |
修復可能なページフォルト |
FLTWATCH* |
ウォッチポイントトラップ |
FLTCPCOVF |
CPU パフォーマンスカウンタオーバーフロー |
BPT、TRACE、BOUNDS は、ブレークポイントとステップ実行を実現するため、dbx で使用されます。これらを操作すると、dbx の動作に影響を及ぼす場合があります。
FLTBPT および FLTTRACE は、ブレークポイントやシングルステップ実行などの dbx の基本機能を妨げることがあるため、無視されます (「イベントの安全性」を参照)。
これらの障害は、/sys/fault.h から抜粋されています。fault には前述の名前を大文字または小文字で指定できるほか、実際のコードも指定できます。また、コードの名前には、接頭辞 FLT- を付けることがあります。
fault イベントは、Linux プラットフォームでは使用できません。
lwp_exit イベントは、lwp が終了したとき、発生します。$lwp には、イベントハンドラを維持している間に終了した LWP (軽量プロセス) の id が含まれます。
lwpexit イベントは、Linux プラットフォームでは使用できません。
sig signal イベントは、デバッグ中のプログラムに信号が初めて送られたとき、発生します。signal は、10 進数、または大文字、小文字の信号名のいずれかです。接頭辞は任意です。このイベントは、catch および ignore コマンドからは完全に独立しています。 ただし、catch コマンドは次のように実現することができます。
function simple_catch { when sig $1 { stop; echo Stopped due to $sigstr $sig whereami } } |
sig イベントを受け取った時点では、プロセスはまだそれを見ることができません。指定の信号を持つプロセスを継続する場合のみ、その信号が転送されます。
指定の sub-code を持つ指定の信号が child に初めて送られたとき、sig signalsub-code イベントが発生します。信号同様、sub-code は 10 進数として、大文字または小文字で入力することができます。 接頭辞は任意です。
指定されたシステムコールが起動された直後で、プロセスがカーネルモードに入ったとき。
dbx の認識するシステムコールは procfs(4) の認識するものに限られます。これらのシステムコールはカーネルでトラップされ、/usr/include/sys/syscall.h に列挙されます。
これは、ABI の言うところのシステムコールとは違います。ABI のシステムコールの一部は部分的にユーザーモードで実装され、非 ABI のカーネルトラップを使用します。ただし、一般的なシステムコールのほとんど (シグナル関係は除く) は syscall.h と ABI で共通です。
sysin イベントは、Linux プラットフォームでは使用できません。
/usr/include/sys/syscall.h 内のカーネルシステムコールトラップのリストは、Solaris OS のプライベートインタフェースの一部です。これはリリースによって異なります。dbx が受け付けるトラップ名 (コード) およびトラップ番号のリストは、dbx がサポートするバージョンの Solaris OS によってサポートされているすべてを含みます。dbx によってサポートされている名前が特定のリリースの Solaris OS でサポートされている名前と性格に一致することはありえないため、syscall.h 内のいくつかの名前は利用可能でない場合があります。すべてのトラップ番号 (コード) は dbx で受け入れられ、予測どおりに動作しますが、既知のシステムコールトラップに対応しない場合は、警告が発行されます。
指定されたシステムコールが終了し、プロセスがユーザーモードに戻る直前。
sysout イベントは、Linux プラットフォームでは使用できません。
引数がないときは、すべてのシステムコールがトレースされます。ここで、modify イベントや RTC (実行時検査) などの特定の dbx は、子プロセスにその目的でシステムコールを引き起こすことがあることに注意してください。 トレースした場合にそのシステムコールの内容が示されることがあります。
次に、実行進行状況に関するイベントのイベント仕様について説明します。
next イベントは、関数がステップされないことを除いては、step イベントと同様です。
このイベントは、現在表示されている関数の戻りのブレークポイントです。表示されている関数を使用するのは、いくつかの up を行なったあとに returns イベント指定を使用できるようにするためです。通常の returns イベントは常に一時イベント (-temp) で、動作中のプロセスが存在する場合にだけ作成できます。
特定の関数がその呼び出し場所に戻るたびに発生します。これは一時イベントではありません。戻り値は示されませんが、SPARC プラットフォームでは $o0、Intel プラットフォームでは $eax を使用して、必須戻り値を調べることができます。
$o0
$eax
$rax, $rdx
このイベントは、次のコードとほとんど同じ働きをします。
when in func { stop returns; } |
step イベントは、ソース行の先頭の命令が実行されると発生します。たとえば、次のようにシンプルに表現することができます。
when step { echo $lineno: $line; }; cont |
step イベントを有効にするということは、次に cont コマンドが使用されるときに自動的にステップ実行できるように dbx に命令することと同じです。
step (および next) イベントは一般的なステップコマンド終了時に発生しません。step コマンドは step イベントで次のように実装されます。alias step="when step -temp { whereami; stop; }; cont"
次に、その他のタイプのイベントに対するイベント仕様を説明します。
dbx がプロセスを正常に接続した直後。
dbx がプロセスを切り離す直前。
デバッグ中のプロセスが終了しようとしています。これは次の理由によって発生します。
システムコール _exit(2) が呼び出し中 (これは、明示的に呼び出されたとき、または main() のリターン時に発生します)。
終了シグナルが送信されようとするとき。
dbx コマンド kill によってプロセスが強制終了されつつあるとき。
プロセスの最終段階は、必ずではありませんが通常はこのイベントが発生したときに利用可能になり、プロセスの状態を確認することができます。このイベントのあとにプログラムの実行を再開すると、プロセスは終了します。
lastrites イベントは、Linux プラットフォームでは使用できません。
dbx がデバッグ中のプロセスと関連しなくなるとき。事前定義済み変数 $reason に、signal、exit、kill、または detach のいずれかが設定されます。
follow exec の結果、新規のプログラムがロードされると、prog_new イベントが発生します。
このイベントのハンドラは常に存在しています。
プロセスが停止したとき。 特に stop ハンドラによりユーザーがプロンプトを受け取るときのようにプロセスが停止すると、このイベントが起動します。次に例を示します。
display x when stop {print x;} |
デバッグ対象のプロセスが exec() で実行された直後。a.out で指定されたメモリーはすべて有効で存在しますが、あらかじめ読み込まれるべき共有ライブラリはまだ読み込まれていません。たとえば printf は dbx に認識されていますが、まだメモリーにはマップされていません。
stop コマンドにこのイベントを指定しても期待した結果は得られません。when コマンドに指定してください。
sync イベントは、Linux プラットフォームでは使用できません。
このイベントは、sync (被デバッグ側が共有ライブラリをまだ処理していない場合は attach) のあとに発生します。 すなわち、動的リンカーの起動時コードが実行され、あらかじめ読み込まれている共有ライブラリすべてのシンボルテーブルが読み込まれたあと、ただし、.init セクション内のコードがすべて実行される前に発生します。
stop コマンドにこのイベントを指定しても期待した結果は得られません。when コマンドに指定してください。
thr_create イベントは、スレッドまたは thread_id の指定されたスレッドが作成されたときに発生します。たとえば、次の stop コマンドでスレッド ID t@1 はスレッド作成を示しますが、スレッド ID t@5 は作成済みスレッドを示しています。
stop thr_create t@5 -thread t@1 |
thr_exit イベントは、スレッドが終了したときに発生します。指定したスレッドの終了を取り込むには、次のように stop コマンドで -thread オプションを使用します。
stop thr_exit -thread t@5 |
処理されない、または予期されない例外がアプリケーションから投げ出されると、throw イベントが発生します。
throw イベントは、Linux プラットフォームでは使用できません。
例外 type が throw イベントで指定されると、そのタイプの例外のみが throw イベントを発生させます。
-unhandled は、投げ出されたが、それに対するハンドラがない例外を示す、特別な例外タイプです。
-unexpected は、それを投げ出した関数の例外仕様を満たさない例外を示す、特別な例外タイプです。
デバッグ中のプログラムが seconds 間実行されると、timer イベントが発生します。このイベントで使用されるタイマーは、collector コマンドで共有されます。解像度はミリ秒であるため、秒の浮動小数点値 (0.001 など) が使用可能です。