GDBはデバッグ対象となるプログラムのファイル名を知っている必要があります。 これは、 プログラムのシンボル・テーブルを読み込むためでもあり、 また、 プログラムを起動するためでもあります。 過去に生成されたコア・ダンプをデバッグするには、 GDBにコア・ダンプ・ファイルの名前を教えてやらなければなりません。
実行ファイルやコア・ダンプ・ファイルの名前を指定したい場合があります。 これは通常、 GDBの起動コマンドへの引数を利用して起動時に行います （GDBの起動と終了参照）。
ときには、 GDBのセッション中に、 異なるファイルに切り替える必要がでてくることがあります。 あるいは、 GDBを起動するときに、 使いたいファイルの名前を指定するのを忘れたということもあるかもしれません。 このような場合に、 新しいファイルを指定するGDBコマンドが便利です。
file filename
runコマンドを使用したときに実行されます。
ユーザがディレクトリを指定せず、
そのファイルがGDBの作業ディレクトリに見つからない場合、
シェルが実行すべきプログラムを探すときと同様、
GDBは、
ファイルを探すべきディレクトリのリストとして環境変数PATHの値を使用します。
pathコマンドによって、
GDB、
ユーザ・プログラムの両方について、
この変数の値を変更することができます。
ファイルをメモリにマップすることのできるシステムでは、
補助的なファイル`filename.syms'に、
ファイルfilenameのシンボル・テーブル情報が格納されることがあります。
このような場合、
GDBは、
`filename.syms'というファイルからシンボル・テーブルをメモリ上にマップすることで、
起動に要する時間を短くします。
詳細については、
（以下に説明するfileコマンド、
symbol-fileコマンド、
add-symbol-fileコマンドを実行する際にコマンドライン上で使用可能な）
ファイル・オプションの`-mapped'、
`-readnow'の説明を参照してください。
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は、
configureによって特定の環境用に構成されると、
その環境において生成される標準フォーマットのデバッグ情報を理解するようになります。
GNUコンパイラを使うこともできますし、
ローカルな環境の規約に従う他のコンパイラを使用することもできます。
通常は、
GNUコンパイラを使用しているときに最高の結果を引き出すことができます。
例えばgccを使用すると、
最適化されたコードに対してデバッグ情報を生成することができます。
COFFを使用する古いSVR3システムを除外すれば、
ほとんどの種類のオブジェクト・ファイルでは、
symbol-fileコマンドを実行しても、
通常は、
ただちにシンボル・テーブルの全体が読み込まれるわけではありません。
実際に存在するソース・ファイルとシンボルを知るために、
シンボル・テーブルを素早く調べるだけです。
詳細な情報は、
後にそれが必要になったときに、
一度に1ソース・ファイルずつ読み込まれます。
2段階に分けて読み込むという手法は、
GDBの起動時間の短縮を目的としています。
ほとんどの場合、
このような手法が採用されているということに気付くことはありません。
せいぜい、
特定のソース・ファイルに関するシンボル・テーブルの詳細が読み込まれている間、
たまに停止するくらいです
（もしそうしたいのであれば、
set verboseコマンドを使うことによって、
このようにして停止しているときにはメッセージを表示させることもできます。
オプションの警告およびメッセージ
を参照してください）。
COFFについては、
まだこの2段階方式を実装していません。
シンボル・テーブルが
COFFフォーマットで格納されている場合、
symbol-fileコマンドはシンボル・テーブル・データの全体をただちに読み込みます。
COFFのstabs拡張フォーマット（stabs-in-COFF）では、
デバッグ情報が実際にはstabsフォーマットの内部に存在するため、
2段階方式が実装されていることに注意してください。
symbol-file filename [ -readnow ] [ -mapped ]
file filename [ -readnow ] [ -mapped ]
mmapシステム・コールによるファイルのメモリへのマッピングがシステム上において有効な場合、
もう1つのオプション
`-mapped'を使って、
GDBに対して、
再利用可能なファイルの中にユーザ・プログラムのシンボルを書き込ませることができます。
後のGDBデバッグ・セッションは、
（プログラムに変更がない場合）
実行プログラムからシンボル・テーブルを読み込むのに時間を費やすことなく、
この補助シンボル・ファイルからシンボル情報をマップします。
`-mapped'オプションを使用することは、
コマンドライン・オプション`-mapped'を指定してGDBを起動するのと同じ効果を持ちます。
補助シンボル・ファイルがユーザ・プログラムのシンボル情報をすべて確実に持つように、
両方のオプションを同時に指定することもできます。
myprogという名前のプログラムの補助シンボル・ファイルは、
`myprog.syms'という名前になります。
このファイルが存在すると、
（それが、
対応する実行ファイルよりも新しい限り）
ユーザがmyprogをデバッグしようとすると、
GDBは常にそのファイルを使おうとします。
特別なオプションやコマンドは必要ありません。
`.syms'ファイルは、
GDBを実行したホスト・マシンに固有のものです。
それは、
GDB内部におけるシンボル・テーブルの正確なイメージを保持しています。
複数のホスト・プラットフォーム間で共用することはできません。
core-file [ filename ]
core-fileを引数なしで実行すると、
コア・ファイルを一切使用しないことを指定したことになります。
ユーザ・プログラムが実際にGDBの管理下で実行中の場合は、
コア・ファイルは無視されることに注意してください。
したがって、
ある時点までユーザ・プログラムを実行させた後に、
コア・ファイルをデバッグしたくなったような場合、
プログラムを実行しているサブ・プロセスを終了させなければなりません。
サブ・プロセスの終了は、
killコマンドで行います
（子プロセスの終了参照）。
add-symbol-file filename address
add-symbol-file filename address [ -readnow ] [ -mapped ]
add-symbol-file filename address data_address bss_address
add-symbol-file filename -Tsection address
add-symbol-fileコマンドは、
filenameで指定されるファイルから追加的なシンボル・テーブル情報を読み込みます。
filenameで指定されるファイルが
（何か別の方法によって）
実行中のプログラムの中に動的にロードされた場合に、
このコマンドを使用します。
addressは、
ファイルがロードされたメモリ・アドレスでなければなりません。
GDBは独力でこのアドレスを知ることはできません。
addressは最大で3個まで指定することができます。
3個のアドレスを指定した場合、
それらはそれぞれ、
textセグメント、
dataセグメント、
bssセグメント
のアドレスとみなされます。
より複雑な場合には、
明示的にセクション名とそのセクションのベース・アドレスを指定するために、
`-Tsection address'
を任意の数だけ指定することができます。
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は、 HP-UX、 SunOS、 SVr4、 Irix 5、 IBM RS/6000の共有ライブラリをサポートします。
ユーザがrunコマンドを実行したり、
コア・ファイルを調べようとすると、
GDBは自動的に共有ライブラリからシンボル定義をロードします
（ユーザがrunコマンドを発行するまでは、
共有ライブラリ内部の関数への参照があっても、
GDBにはそれを理解することができません。
コア・ファイルをデバッグしている場合は、
この限りではありません）。
HP-UX上では、
プログラムがライブラリを明示的にロードする場合は、
shl_loadの呼び出しの時点において、
GDBが自動的にシンボルをロードします。
info share
info sharedlibrary
sharedlibrary regex
share regex
runコマンド実行時に必要とされる共有ライブラリだけがロードされます。
regexが省略されると、
ユーザ・プログラムによって必要とされるすべての共有ライブラリがロードされます。
HP-UXシステムでは、 GDBは共用ライブラリのローディングを検出し、 新しくロードされたライブラリから自動的にシンボルを読み込みます。 この読み込みは、 ある上限まで行われます。 この上限の値は、 最初にセットされますが、 そうしたければ変更することも可能です。
上限を超えた共用ライブラリのシンボルは、
明示的にロードされなければなりません。
これらのシンボルをロードするには、
sharedlibrary filenameコマンドを使用します。
共用ライブラリのベース・アドレスはGDBによって自動的に決定されるので、
指定する必要はありません。
上限を表示またはセットするには、 以下のコマンドを使用します。
set auto-solib-add threshold
sharedlibraryコマンドを使用して、
手作業でロードしなければなりません。
デフォルトの上限は、
100メガバイトです。
show auto-solib-add
シンボル・ファイルの読み込み中に、
GDBはときどき問題にぶつかることがあります。
例えば、
認識できないシンボル・タイプを見つけたり、
コンパイラの出力に既知の問題を発見することがあります。
デフォルトでは、
このようなエラーがあったことを、
GDBはユーザに知らせません。
なぜなら、
このようなエラーは比較的よく見られるものであり、
コンパイラのデバッグをしているような人々だけが関心を持つようなものだからです。
もし、
正しく構築されていないシンボル・テーブルに関する情報を見ることに関心があれば、
set complaintsコマンドを使用することで、
問題が何回発生しようと個々のタイプの問題について1回だけメッセージを出力するよう指示することができますし、
また、
問題が何回発生したかを見るためにより多くのメッセージを表示するよう指示することもできます
（オプションの警告およびメッセージ参照）。
現在のバージョンで表示されるメッセージとその意味を以下に記します。
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という名前を持つものとみなすことによって、
この問題を回避します。
この結果、
多くのシンボルがfooという名前を持つことになってしまうと、
他の問題が発生する可能性があります。
unknown symbol type 0xnn
0xnnは理解できなかったシンボルの型を16進数で表わしたものです。
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