gdb progm core
`progm' が実行可能なプログラムであり、`core' が
コアダンプした調査用ファイルだと指定したことになります(プログラムを
対話的にデバッグする場合、このコアダンプ・ファイルは必要では
ありません)。
GDB を起動する時のオプションと引数に関する全ての 説明は、“12 GDB のオプションと引数”を参照して下さい。
PATH を使って、
シェルが実行対象のプログラムを探すのと同様の方法でファイルを
見つけます。
PATH が検索されます。
ほとんどの場合、あなたは `exec-file' と
`symbol-file' コマンドを同一のファイルに対して用いるでしょう。
引数なしの `symbol-file' は、GDB のシンボルテーブルを クリアします。
`symbol-file' コマンドは、すぐに全てのシンボルを読み込んでしまう わけではありません。そのかわり、このコマンドはどんなソースファイルと どのようななシンボルが与えられたのかを調べるために、シンボルテーブルを 高速にスキャンします。詳細は、必要が生じた時、一つのソースファイル 単位に後から読み込まれます。
この2ステージ読み込み方式の目的は、GDB の起動を早くすることにあります。 シンボルテーブルの詳細を調べるために、個々のソースファイルが読み込まれて いることをあなたに対して報告する臨時メッセージを除いて、 たいていの場合これらのことは目につきません(`set verbose' コマンドは、表示されるこれらのメッセージを コントロールします; “1 GDB の入出力の慣例”をご覧下さい)。
しかしながら、あなたは時々、まだソースファイル内のデータが読み 込まれていない関数に関するバックトレース結果を見てしまう場合が あるでしょう; これらの出力では、シンボルテーブルの詳細がないと 表示できないような引数の値といった情報が、省略表示されています。
シンボルテーブルが COFF フォーマットで格納されていた場合、 `symbol-file' は全てのシンボルテーブル・データを即座に 読み込みます。私たちは、COFF に対して2ステージ読み込み方式を わざわざインプリメントするつもりはありません。
引数なしの `core-file' は、コアファイルを使用しないことを意味 します。
あなたのプログラムが GDB の下で実際に動作している時、コアファイルは 無視されることに注意して下さい。プログラム実行中にコアファイルを デバッグしたくなった場合、動作中のプログラムのサブプロセスを kill する必要があります。この場合、`kill' コマンドを利用して 下さい(“4.6 チャイルドプロセスを kill するには”をご覧下さい)。
filename のシンボルテーブルは、初めは `symbol-file' コマンド によってシンボルテーブルに追加されます。あなたは、 `add-file' コマンドをいつでも利用できます; 従って、新しいシンボルデータは、古いものに追加保持されます。 `symbol-file' コマンドは GDB が既に読み込んだ全てのシンボル データを忘れてしまいます; これは、GDB においてシンボルデータが忘れ去られる唯一のケースです。
`symbol-file' コマンドは、簡易変数、変数履歴、そして全ての ブレークポイントと自動表示する式を GDB に忘れさせます。これは、 これらの情報が、GDB の中から捨てられる古いシンボルデータの一部として、 内部的に記憶されているシンボルとデータ型へのポインタを持っている からです。