Next: , Previous: GDB Files, Up: GDB Files


12.1 ファイルを指定するコマンド

実行ファイルやコア・ダンプ・ファイルの名前を指定したい場合があります。 これは通常、 GDBの起動コマンドへの引数を利用して、 起動時に行います (see Getting In and Out of GDB)。

ときには、 GDBのセッション中に、 異なるファイルに切り替える必要がでてくることがあります。 あるいは、 GDBを起動するときに、 使いたいファイルの名前を指定するのを忘れたということもあるかもしれません。 このような場合に、 新しいファイルを指定するGDBコマンドが便利です。

file filename
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 ]
実行するプログラムがfilenameで指定されるファイル内に存在する (ただし、 シンボル・テーブルはそこには存在しない) ということを指定します。 GDBは、 必要であれば、 ユーザ・プログラムの存在場所を見つけるために、 環境変数PATHを使用します。 filenameを指定しないと、 実行ファイルに関して保持している情報を破棄するよう指示したことになります。


symbol-file [ filename ]
filenameで指定されるファイルからシンボル・テーブル情報を読み込みます。 必要な場合にはPATHが検索されます。 同一のファイルから、 シンボル・テーブルと実行プログラムの両方を獲得する場合には、 fileコマンドを使用してください。

symbol-fileを引数なしで実行すると、 GDBがユーザ・プログラムのシンボル・テーブルに関して持っている情報は消去されます。

symbol-fileコマンドが実行されると、 それまでGDBが保持していたコンビニエンス変数、 値ヒストリ、 すべてのブレイクポイント、 自動表示式は破棄されます。 その理由は、 これらの情報の中に、 GDBが破棄した古いシンボル・テーブルのデータの一部である、 シンボルやデータ型を記録する内部データへのポインタが含まれているかもしれないからです。

symbol-fileを一度実行した後に<RET>キーを押しても、 symbol-fileの実行は繰り返されません。

GDBは、 特定の環境用に構成されると、 その環境において生成される標準フォーマットのデバッグ情報を理解するようになります。 gnuコンパイラを使うこともできますし、 ローカルな環境の規約に従う他のコンパイラを使用することもできます。 通常は、 gnuコンパイラを使用しているときに最高の結果を引き出すことができます。 例えばgccを使用すると、 最適化されたコードに対してデバッグ情報を生成することができます。

COFFを使用する古いSVR3システムを除外すれば、 ほとんどの種類のオブジェクト・ファイルでは、 symbol-fileコマンドを実行しても、 通常は、 ただちにシンボル・テーブルの全体が読み込まれるわけではありません。 実際に存在するソース・ファイルとシンボルを知るために、 シンボル・テーブルを素早く調べるだけです。 詳細な情報は、 後にそれが必要になったときに、 一度に1ソース・ファイルずつ読み込まれます。

2段階に分けて読み込むという手法は、 GDBの起動時間の短縮を目的としています。 ほとんどの場合、 このような手法が採用されているということに気付くことはありません。 せいぜい、 特定のソース・ファイルに関するシンボル・テーブルの詳細が読み込まれている間、 たまに停止するくらいです (もしそうしたいのであれば、 set verboseコマンドを使うことによって、 このようにして停止しているときにはメッセージを表示させることもできます。 See Optional warnings and messages)。

COFFについては、 まだこの2段階方式を実装していません。 シンボル・テーブルが COFFフォーマットで格納されている場合、 symbol-fileコマンドはシンボル・テーブル・データの全体をただちに読み込みます。 COFFのstabs拡張フォーマット(stabs-in-COFF)では、 デバッグ情報が実際にはstabsフォーマットの内部に存在するため、 2段階方式が実装されていることに注意してください。


symbol-file filename [ -readnow ] [ -mapped ]
file filename [ -readnow ] [ -mapped ]
GDBが確実にシンボル・テーブル全体を保持しているようにしたいのであれば、 シンボル・テーブル情報を読み込む任意のコマンド実行時に ‘-readnow’オプションを使用することで、 2段階によるシンボル・テーブル読み込み方式を使わないようにさせることができます。

mmapシステム・コールによるファイルのメモリへのマッピングがシステム上において有効な場合、 もう1つのオプション ‘-mapped’を使って、 GDBに対して、 再利用可能なファイルの中にユーザ・プログラムのシンボルを書き込ませることができます。 後のGDBデバッグ・セッションは、 (プログラムに変更がない場合) 実行プログラムからシンボル・テーブルを読み込むのに時間を費やすことなく、 この補助シンボル・ファイルからシンボル情報をマップします。 ‘-mapped’オプションを使用することは、 コマンドライン・オプション‘-mapped’を指定してGDBを起動するのと同じ効果を持ちます。

補助シンボル・ファイルがユーザ・プログラムのシンボル情報をすべて確実に持つように、 両方のオプションを同時に指定することもできます。

myprogという名前のプログラムの補助シンボル・ファイルは、 ‘myprog.syms’という名前になります。 このファイルが存在すると、 (それが、 対応する実行ファイルよりも新しい限り) ユーザがmyprogをデバッグしようとすると、 GDBは常にそのファイルを使おうとします。 特別なオプションやコマンドは必要ありません。

.symsファイルは、 GDBを実行したホスト・マシンに固有のものです。 それは、 GDB内部におけるシンボル・テーブルの正確なイメージを保持しています。 複数のホスト・プラットフォーム間で共用することはできません。


core-file [ filename ]
「メモリ上のイメージ」として使用されるコア・ダンプ・ファイルの存在場所を指定します。 伝統的に、 コア・ファイルは、 それを生成したプロセスのアドレス空間の一部だけを保持しています。 GDBは、 実行ファイルそのものにアクセスすることによって、 保持されていない部分を獲得することができます。

core-fileを引数なしで実行すると、 コア・ファイルを一切使用しないことを指定したことになります。

ユーザ・プログラムが実際にGDBの管理下で実行中の場合は、 コア・ファイルは無視されることに注意してください。 したがって、 ある時点までユーザ・プログラムを実行させた後に、 コア・ファイルをデバッグしたくなったような場合、 プログラムを実行しているサブ・プロセスを終了させなければなりません。 サブ・プロセスの終了は、 killコマンドで行います (see Killing the child process)。


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 filesinfo targetは同義です。 両方とも、 カレント・ターゲット (see Specifying a Debugging Target) に関する情報を表示します。 表示される情報には、 GDBが現在使用中の 実行ファイルやコア・ダンプ・ファイル の名前、 シンボルがそこからロードされたファイルの名前を含みます。 help targetコマンドは、 カレントなターゲットではなく、 すべての可能なターゲットを一覧表示します。

ファイルを指定するすべてのコマンドは、 引数として、 絶対パスによるファイル名と相対パスによるファイル名のどちらでも受け付けます。 GDBは、 常にファイル名を絶対パス名に変換して、 絶対パスの形で記憶します。

GDBは、 HP-UX、 SunOS、 SVr4、 Irix 5、 IBM RS/6000の共有ライブラリをサポートします。 ユーザがrunコマンドを実行したり、 コア・ファイルを調べようとすると、 GDBは自動的に共有ライブラリからシンボル定義をロードします (ユーザがrunコマンドを発行するまでは、 共有ライブラリ内部の関数への参照があっても、 GDBにはそれを理解することができません。 コア・ファイルをデバッグしている場合は、 この限りではありません)。

info share
info sharedlibrary
現在ロードされている共有ライブラリの名前を表示します。


sharedlibrary regex
share regex
UNIXの正規表現にマッチするファイルに対応する、 共有オブジェクト・ライブラリのシンボルをロードします。 自動的にロードされるファイルと同様、 ユーザ・プログラムによってコア・ファイルのために必要とされる共有ライブラリ、 または runコマンド実行時に必要とされる共有ライブラリだけがロードされます。 regexが省略されると、 ユーザ・プログラムによって必要とされるすべての共有ライブラリがロードされます。