Next: Signals, Previous: Breakpoints, Up: Stopping
継続実行とは、
ユーザ・プログラムの実行を再開して、
それが正常に終了するまで実行させることを指します。
一方、
ステップ実行とは、
ユーザ・プログラムを1「ステップ」だけ実行することを指します。
ここで「ステップ」とは、
(使用されるコマンドによって)
1行のソース・コードを指すこともありますし、
1マシン命令を指すこともあります。
継続実行の場合でもステップ実行の場合でも、
ブレイクポイントやシグナル
が原因となって、
正常終了する前にユーザ・プログラムが停止することがあります
(シグナルによってプログラムが停止した場合、
実行を再開するには
handle
コマンドまたは‘signal 0’
コマンドを使用するとよいでしょう。
See Signals)
。
continue
[ignore-count]c
[ignore-count]fg
[ignore-count]ignore
コマンドと似た効果を持ちます
(see Break conditions)。
引数ignore-countは、
ユーザ・プログラムがブレイクポイントによって停止した場合にのみ意味を持ちます。
これ以外の場合には、
continue
コマンドへの引数は無視されます。
c
およびfg
は、
簡便さのためだけに提供されている同義コマンドで、
continue
コマンドと全く同様の動作をします。
別の箇所で実行を再開するには、
呼び出し関数に戻るreturn
コマンド
(see Returning from a function)、
または、
ユーザ・プログラム内の任意の箇所へ移動するjump
コマンド
(see Continuing at a different address)
を使用することができます。
ステップ実行を使用する典型的なテクニックは、 問題があると思われる関数やプログラム部分の先頭にブレイクポイント (see Breakpoints; watchpoints; and catchpoints) を設定し、 ブレイクポイントで停止するまでプログラムを実行させた後、 問題が再現するまで、 関連しそうな変数の値を調べながら、 疑わしい部分を1行ずつ実行することです。
step
s
です。
注意: デバッグ情報なしでコンパイルされた関数の内部にいるときにstep
コマンドを使用すると、 デバッグ情報付きの関数に達するまでプログラムの実行は継続されます。 同様に、step
コマンドがデバッグ情報なしでコンパイルされた関数の内部へ入って、 停止することはありません。 デバッグ情報を持たない関数の内部でステップ実行を行うには、 後述のstepi
コマンドを使用してください。
step
コマンドは、
ソース・コード行の最初の命令においてのみ停止するようになりました。
これにより、
以前のバージョンで発生していた、
switch
文やfor
文などにおいて複数回停止してしまうという問題が回避されています。
同じ行の中にデバッグ情報を持つ関数への呼び出しがあると、
step
コマンドは続けて停止します。
さらに、
step
コマンドは、
サブルーチンが行番号情報を持つ場合に限り、
サブルーチンの内部に入り込むようになりました。
サブルーチンが行番号情報を持たない場合、
step
コマンドはnext
コマンドと同様の動作をします。
これにより、
MIPSマシン上でcc -gl
を使用した場合に発生していた問題が回避されています。
以前のバージョンでは、
サブルーチンが何らかのデバッグ情報を持っていれば、
その内部に入り込んでいました。
step
countstep
コマンドによるステップ実行をcount回繰り返します。
ステップ実行をcount回繰り返し終わる前に、
ブレイクポイントに到達する
か、
あるいは、
ステップ実行とは関連のないシグナルが発生した
場合には、
ただちにステップ実行を中断して停止します。
next
[count]step
コマンドと似ていますが、
next
コマンドは、
ソース・コード上に関数呼び出しが存在すると、
その関数を停止することなく最後まで実行します。
プログラムが停止するのは、
next
コマンドを実行したときと同一のスタック・フレーム上において、
ソース・コード上の異なる行まで実行が継続されたときです。
このコマンドの省略形はn
です。
引数countは、
step
コマンドの場合と同様、
繰り返し回数です。
next
コマンドは、
ソース・コード行の最初の命令においてのみ停止するようになりました。
これにより、
以前のバージョンで発生していた、
switch
文やfor
文などにおいて複数回停止してしまうという問題が回避されています。
finish
return
コマンド
(see Returning from a function)
と比較してみてください。
until
u
next
コマンドに似ていますが、
唯一の相違点は、
until
コマンドによってジャンプ命令が実行された場合、
プログラム・カウンタの値がジャンプ命令のアドレスより大きくなるまで、
プログラムが継続実行されるという点です。
これは、
ステップ実行によってループ内の最後の行に到達した後にuntil
コマンドを実行することで、
ループから抜け出るまでプログラムを継続実行させることができるということを意味しています。
これに対して、
ループ内の最後の行でnext
コマンドを実行すると、
プログラムはループの先頭に戻ってしまうので、
ループ内の処理を繰り返すことを余儀なくされます。
until
コマンドの実行により、
プログラムがカレントなスタック・フレームから抜け出ようとすると、
そこでuntil
コマンドはプログラムを停止します。
実行されるマシン・コードの順序がソース行の順序と一致しない場合、
until
コマンドは直観にいくらか反するような結果をもたらすかもしれません。
例えば、
以下に挙げるデバッグ・セッションからの抜粋では、
f
(frame
)
コマンドによって、
プログラムが206
行めにおいて停止していることが示されています。
ところが、
until
コマンドを実行すると、
195
行めで停止してしまいます。
(gdb) f #0 main (argc=4, argv=0xf7fffae8) at m4.c:206 206 expand_input(); (gdb) until 195 for ( ; argc > 0; NEXTARG) {
これは、
コンパイラが、
実行の効率を高めるために、
C言語では
for
ループ本体の前に記述されているループ終了のための条件判定を、
ループの先頭ではなく末尾で行うコードを生成したためです。
この判定式にまで処理が進んだとき、
until
コマンドはあたかもループの先頭に戻ったかのように見えます。
しかしながら、
実際のマシン・コードのレベルでは、
前の命令に戻ったわけではありません。
引数のないuntil
コマンドは、
1命令ごとのステップ実行によって実現されるため、
引数付きの
until
コマンドに比べて処理性能が劣ります。
until
locationu
locationbreak
コマンドの受け付ける形式の引数です
(see Setting breakpoints)。
この形式によるuntil
コマンドはブレイクポイントを使用するため、
引数のないuntil
コマンドより処理性能が優れています。
stepi
si
マシン命令単位でステップ実行する場合、 ‘display/i $pc’を使用すると便利なことがしばしばあります。 これは、 ユーザ・プログラムが停止するたびに、 次に実行される命令をGDBに自動的に表示させます。 See Automatic display。
引数として、
step
コマンドと同様、
繰り返し回数を取ります。
nexti
ni
引数として、next
コマンドと同様、
繰り返し回数を取ります。