通常、あなたは、GDB が解析すべきファイルを GDB 起動時の引数として 与えることでしょう。しかし、時々、GDB セッション中に異なった ファイルに変更する必要が発生することがあります。また、利用したい ファイル名の記述を忘れたまま GDB を起動してしまうこともあるでしょう。 これらの状況に陥った時は、新しいファイルを記述するための GDB の コマンドが便利です。
exec-file filename
PATH
を使って、
シェルが実行対象のプログラムを探すのと同様の方法でファイルを
見つけます。
symbol-file filename
PATH
が検索されます。
ほとんどの場合、あなたは `exec-file' と
`symbol-file' コマンドを同一のファイルに対して用いるでしょう。
引数なしの `symbol-file' は、GDB のシンボルテーブルを
クリアします。
`symbol-file' コマンドは、すぐに全てのシンボルを読み込んでしまう
わけではありません。そのかわり、このコマンドはどんなソースファイルと
どのようななシンボルが与えられたのかを調べるために、シンボルテーブルを
高速にスキャンします。詳細は、必要が生じた時、一つのソースファイル
単位に後から読み込まれます。
この2ステージ読み込み方式の目的は、GDB の起動を早くすることにあります。
シンボルテーブルの詳細のための個々のソースファイルが読み込まれて
いることをあなたに対して報告する臨時メッセージを除いて、
たいていの場合これらのことは目につきません(`set verbose'
コマンドは、表示されるこれらのメッセージを
コントロールします; see section GDB の入出力の慣例)。
しかしながら、あなたは時々、まだソースファイル内のデータが読み
込まれていない関数に関するバックトレース結果を見る場合が
あるでしょう; これらの出力では、シンボルテーブルの詳細がないと
表示できないような引数の値といった情報が、省略表示されています。
シンボルテーブルが COFF フォーマットで格納されていた場合、
`symbol-file' は全てのシンボルテーブル・データを即座に
読み込みます。私たちは、COFF に対して2ステージ読み込み方式を
わざわざインプリメントするつもりはありません。
core-file filename
add-file filename address
info files
これら3つのファイル記述用コマンドは、引数として絶対・相対パスの ファイル名を引数として許していますが、GDB はファイル名を絶対パスに 変換し、それを記憶しています。
`symbol-file' コマンドは、簡易変数、変数履歴、そして全ての ブレークポイントと自動表示する式を GDB に忘れさせます。これは、 これらの情報が、GDB の中から捨てられる古いシンボルデータの一部として、 内部的に記憶されているシンボルとデータ型へのポインタを持っている からです。