GDBはデバッグ対象となるプログラムのファイル名を知っている必要があります。 これは、 プログラムのシンボル・テーブルを読み込むためでもあり、 また、 プログラムを起動するためでもあります。 過去に生成されたコア・ダンプをデバッグするには、 GDBにコア・ダンプ・ファイルの名前を教えてやらなければなりません。
実行ファイルやコア・ダンプ・ファイルの名前を指定したい場合があります。 これは通常、 起動時にGDBの起動コマンドへの引数を利用して行います （GDBの起動・終了を参照）。 時には、 GDBのセッション中に、 異なるファイルに切り替える必要がでてくることがあります。 あるいは、 GDBを起動するときに、 使いたいファイルの名前を指定するのを忘れたということもあるかもしれません。 このような場合に、 新しいファイルを指定するGDBコマンドが便利です。
file filename
runコマンドを使用したときに実行されます。
ユーザがディレクトリを指定せず、
そのファイルがGDBの作業ディレクトリに見つからない場合、
シェルが実行すべきファイルを探すときと同様、
GDBは環境変数PATHの値をファイルを探すべきディレクトリのリストとして使用します。
GDB、
ユーザ・プログラムの両方について、
この変数の値をpathコマンドによって変更することができます。
ファイルをメモリにマップすることのできるシステムでは、
補助的なファイル`filename.syms'が、
ファイルfilenameのシンボル・テーブル情報を格納することができます。
このような場合、
GDBは`filename.syms'というファイルからシンボル・テーブルをメモリ上にマップすることで、
起動に要する時間を短くします。
詳細については、
ファイル・オプションの`-mapped'、
`-readnow'
（これらは、
コマンドライン上で、
以下に説明するfile、
symbol-file、
add-symbol-fileコマンドで使用できます）
の説明を参照してください。
file
fileコマンドを引数なしで実行すると、
GDBは実行ファイル、
シンボル・テーブルに関して保持している情報をすべて破棄します。
exec-file [ filename ]
PATHを使用します。
filenameを指定しないと、
実行ファイルに関して保持している情報を破棄することを意味します。
symbol-file [ filename ]
PATHが検索されます。
同一のファイルから、
シンボル・テーブルと実行プログラムの両方を獲得する場合には、
fileコマンドを使用してください。
symbol-fileを引数なしで実行すると、
ユーザ・プログラムのシンボル・テーブルに関してGDBが持っている情報が消去されます。
symbol-fileが実行されると、
それまでGDBが保持していたコンビニエンス変数、
値ヒストリ、
すべてのブレイクポイント、
自動表示式は破棄されます。
これらの情報の中には、
GDBが破棄した古いシンボル・テーブルのデータの一部であるシンボルやデータ型を記録する内部データへのポインタが含まれているかもしれないからです。
symbol-fileを一度実行した後にRETキーを押しても、
symbol-fileの実行は繰り返されません。
GDBは、
特定の環境用に設定されると、
その環境において生成される標準のフォーマットにおけるデバッグ情報を理解するようになります。
GNUコンパイラを使うこともできますし、
ローカルな環境の規約に従う他のコンパイラを使用することもできます。
通常はGNUコンパイラを使用しているときに、
最高の結果を引き出すことができます。
例えば、
gccを使うと最適化されたコードに対してデバッグ情報を生成することができます。
ある種のオブジェクト・ファイルにおいては、
symbol-fileコマンドを実行しても、
通常はただちにシンボル・テーブルの全体が読み込まれるわけではありません。
存在するソース・ファイル名とシンボル名とを知るために、
シンボル・テーブルを素早く調べるだけです。
詳細な情報は、
後にそれが必要になったときに、
一度に１ソース・ファイルずつ読み込まれます。
２段階に分けて読み込むこの手法の目的は、
GDBの起動時間の短縮です。
ほとんどの場合、
特定のソース・ファイルに関するシンボル・テーブルの詳細が読み込まれている間の若干の停止を除けば、
このような手法を採用しているということを示すものはありません
（もしそうしたいのであれば、
set verboseコマンドを使うことによって、
これらの停止をメッセージとして表示させることもできます。
オプションの警告およびメッセージを参照してください）。
COFFについては、
まだこの２段階方式を実装していません。
シンボル・テーブルが
COFFフォーマットで格納されている場合、
symbol-fileコマンドはシンボル・テーブル・データの全体をただちに読み込みます。
symbol-file filename [ -readnow ] [ -mapped ]
file filename [ -readnow ] [ -mapped ]
mmapシステム・コールによるファイルのメモリへのマッピングがシステム上において有効な場合、
もう１つのオプション
`-mapped'を使って、
GDBにユーザ・プログラムのシンボルを再利用可能なファイルに書き込ませることができます。
後のGDBデバッグ・セッションは、
（プログラムに変更がない場合）
実行プログラムからシンボル・テーブルを読み込むのに時間を費やすことなく、
この補助シンボル・ファイルからシンボル情報をマップします。
`-mapped'オプションを使用することは、
コマンドライン・オプション`-mapped'を指定してGDBを起動するのと同等の効果を持ちます。
補助シンボル・ファイルがユーザ・プログラムのシンボル情報をすべて確実に持つように、
両方のオプションを同時に指定することもできます。
myprogという名のプログラムの補助シンボル・ファイルは、
`myprog.syms'という名になります。
このファイルが存在すると、
（それが、
対応する実行ファイルよりも新しい限り）
ユーザがmyprogをデバッグしようとするとGDBは常にそのファイルを使おうとします。
特別なオプションやコマンドは必要ありません。
`.syms'ファイルは、
GDBを実行したホスト・マシンに固有のものです。
それは、
GDB内部におけるシンボル・テーブルの正確なイメージを保持しています。
複数のホスト・プラットフォーム間で共用することはできません。
core-file [ filename ]
core-fileを引数なしで実行すると、
コア・ファイルを一切使用しないことを指定したことになります。
ユーザ・プログラムが実際にGDBの管理下で実行中の場合は、
コア・ファイルは無視されることに注意してください。
したがって、
ある時点までユーザ・プログラムを実行させた後に、
コア・ファイルをデバッグしたくなったような場合、
プログラムを実行しているサブ・プロセスを終了させなければなりません。
サブ・プロセスの終了は、
killコマンドで行います
（子プロセスの終了を参照）。
load filename
loadコマンドが使用可能になります。
これが利用可能な場合、
実行ファイルfilenameが
（例えば、
ダウンロードやダイナミック・リンクによって）
リモート・システム上でデバッグできるようになることを意味します。
また、
loadコマンドはadd-symbol-fileコマンドと同様、
ファイルfilenameのシンボル・テーブルをGDB内に記録します。
GDBがloadコマンドを提供していない場合、
それを実行しようとすると
「You can't do that when your target is ...」
というエラー・メッセージが表示されます。
実行ファイルの中で指定されたアドレスにファイルはロードされます。
オブジェクト・ファイルのフォーマットによっては、
プログラムをリンクするときに、
ファイルをロードするアドレスを指定できるものもあります。
このようなフォーマット以外
（例えば、
a.out）
では、
オブジェクト・ファイルのフォーマットによって固定的にアドレスが指定されます。
VxWorksでloadコマンドを実行すると、
filenameで指定される実行ファイルがカレントなターゲット・システム上で動的にリンクされ、
シンボルがGDBに追加されます。
Intel 960ボードのNindyインターフェイスでは、
loadコマンドはfilenameで指定されるファイルをダウンロードし、
そのシンボルをGDBに追加します。
日立のSH、
H8/300、
H8/500ボード
（GDBと日立のマイクロ・プロセッサを参照）
に対するリモート・デバッグを選択すると、
loadコマンドはユーザ・プログラムを日立ボードにダウンロードし、
（fileコマンドと同様）
ユーザのホスト・マシン上のGDBのカレントなターゲット実行モジュールとしてオープンします。
loadコマンドを実行後RETキーを押しても、
loadコマンドは繰り返し実行されません。
add-symbol-file filename address
add-symbol-file filename address [ -readnow ] [ -mapped ]
add-symbol-fileコマンドは、
filenameで指定されるファイルから追加的なシンボル・テーブル情報を読み込みます。
実行中のプログラムが
（何か別の方法によって）
filenameで指定されるファイルを動的にロードした場合に、
このコマンドを使用します。
addressは、
ファイルがロードされたメモリ・アドレスでなければなりません。
GDBは独力でこのアドレスを知ることはできません。
addressは式として指定することもできます。
filenameで指定されるファイルのシンボル・テーブルは、
もともとsymbol-fileコマンドによって読み込まれたシンボル・テーブルに追加されます。
add-symbol-fileコマンドは何回でも使用することができます。
新たに読み込まれたシンボル・テーブルのデータは、
古いデータに追加されていきます。
古いシンボル・データをすべて破棄するには、
symbol-fileコマンドを使用してください。
add-symbol-fileコマンドを実行後RETキーを押しても、
add-symbol-fileコマンドは繰り返し実行されません。
symbol-fileコマンドと同様、
`-mapped'オプションと`-readnow'オプション使用して、
filenameで指定されるファイルのシンボル・テーブル情報をGDBがどのように管理するかを変更することができます。
add-shared-symbol-file
add-shared-symbol-fileコマンドは、
Motorola 88k用のHarris' CXUXオペレーティング・システム上でのみ使用することができます。
GDBは自動的に共有ライブラリを探しますが、
GDBがユーザの共有ライブラリを見つけてくれない場合、
add-shared-symbol-fileコマンドを実行できます。
このコマンドは引数を取りません。
section
sectionコマンドは、
実行ファイルのsectionセクションのベース・アドレスをaddrに変更します。
これは、
（a.outフォーマットのように）
実行ファイルがセクション・アドレスを保持していない場合や、
ファイル内に指定されたアドレスが誤っている場合に使うことができます。
個々のセクションは、
個別に変更されなければなりません。
`info files'コマンドによって、
すべてのセクションとそのアドレスを一覧表示することができます。
info files
info target
info filesとinfo targetは同義です。
両方とも、
カレント・ターゲット
（デバッグ・ターゲットの指定を参照）
に関する情報を表示します。
表示される情報には、
GDBがその時点で使用している実行ファイル
やコア・ダンプ・ファイル
の名前、
シンボルがそこからロードされたファイルの名前を含みます。
help targetコマンドは、
カレントなターゲットではなく、
すべての可能なターゲットを一覧表示します。
ファイルを指定するコマンドはすべて、
引数として絶対パスでのファイル名と相対パスでのファイル名の両方を取ることができます。
GDBはファイル名を常に絶対パス名に変換し、
絶対パスの形で記憶します。
GDBは、
SunOS、
SVr4、
Irix5、
IBM RS/6000の共有ライブラリをサポートします。
ユーザがrunコマンドを実行したり、
コア・ファイルを調べようとすると、
GDBは自動的に共有ライブラリからシンボル定義をロードします
（ユーザがrunコマンドを発行するまでは、
GDBは共有ライブラリ内部の関数への参照を理解しません。
コア・ファイルをデバッグしている場合は、
この限りではありません）。
info share
info sharedlibrary
sharedlibrary regex
share regex
runコマンド実行時に必要とされる共有ライブラリのみをロードします。
regexが省略されると、
ユーザ・プログラムによって必要とされるすべての共有ライブラリがロードされます。
シンボル・ファイルを読み込み中に、
GDBは時々問題にぶつかることがあります。
例えば、
認識できないシンボル・タイプを見つけたり、
コンパイラの出力に既知の問題を発見することがあります。
デフォルトでは、
GDBはこのようなエラーがあったことをユーザに知らせません。
なぜなら、
このようなエラーは比較的よく見られるものであり、
コンパイラのデバッグをしているような人々のみが関心を持つようなものだからです。
もし、
正しく構築されていないシンボル・テーブルに関する情報を見ることに関心があれば、
set complaintsコマンドを使用することで、
何回問題が発生しようと個々のタイプの問題について１回だけメッセージを出力するよう指示することもできますし、
何回問題発生したかを見るためにより多くのメッセージを表示するよう指示することもできます
（オプションの警告およびメッセージを参照）。
現在のバージョンで表示されるメッセージとその意味を以下に記します。
inner block not inside outer block in symbol
(don't know)'のように表示されることがあります。
block at address out of order
set verbose onを指定することで、
どのソース・ファイルが関係しているかを知ることができます。
オプションの警告およびメッセージを参照してください）。
bad block start address patched
bad string table offset in symbol n
fooという名前を持つものとみなすことによって、
この問題を回避します。
この結果、
多くのシンボルがこの名前を持つことになってしまうと、
他の問題が発生する可能性があります。
unknown symbol type 0xnn
0xnnは理解できなかったシンボルの型を１６進数で表したものです。
GDBは、
このようなシンボル情報を無視することによって、
このエラーを回避します。
この場合、
ユーザはプログラムのデバッグを行うことは可能ですが、
ある特定のシンボルにアクセスすることができなくなります。
このような問題にぶつかり、
それをデバッグしたいのであれば、
gdb自身を使ってgdbをデバッグすることができます。
この場合、
シンボルcomplainにブレイクポイントを設定し、
関数read_dbx_symtabまで実行してから、
*bufpによってシンボルを参照します。
stub type has NULL name
const/volatile indicator missing (ok if using g++ v1.x), got...
info mismatch between compiler and debugger