次: Signals, 前: Breakpoints, 上: 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行ずつ実行することです。
stepsです。
注意: デバッグ情報なしでコンパイルされた関数の内部にいるときに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文などにおいて複数回停止してしまうという問題が回避されています。
finishreturnコマンド
（see Returning from a function）
と比較してみてください。
untilunextコマンドに似ていますが、
唯一の相違点は、
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コマンドより処理性能が優れています。
stepisiマシン命令単位でステップ実行する場合、 `display/i $pc'を使用すると便利なことがしばしばあります。 これは、 ユーザ・プログラムが停止するたびに、 次に実行される命令をGDBに自動的に表示させます。 See Automatic display。
引数として、
stepコマンドと同様、
繰り返し回数を取ります。
nextini引数として、nextコマンドと同様、
繰り返し回数を取ります。