ターゲットとは、
ユーザ・プログラムの実行環境を指します。
多くの場合、
GDBはユーザ・プログラムと同一のホスト環境上で実行されます。
この場合には、
fileコマンドやcoreコマンドを実行すると、
その副作用としてデバッグ・ターゲットが指定されます。
例えば、
物理的に離れた位置にあるホスト・マシン上でGDBを実行したい場合や、
シリアル・ポート経由でスタンドアロン・システムを制御したい場合、
もしくは、
TCP/IP接続を利用してリアルタイム・システムを制御したい場合などのように、
より多くの柔軟性が必要とされる場合、
targetコマンドを使ってGDBに設定されたターゲットの種類から１つを指定することができます
（ターゲットを管理するコマンドを参照）。
ターゲットには３つのクラスがあります。
プロセス、コア・ファイル、
そして、
実行ファイルです。
GDBは同時に、
１クラスにつき１つ、
全体で最高で３つまでアクティブなターゲットを持つことができます。
これにより、
（例えば）
コア・ファイルに対して行ったデバッグ作業を破棄することなく、
プロセスを起動してその動作を調べることができます。
例えば、
`gdb a.out'を実行すると、
実行ファイルa.outが唯一のアクティブなターゲットになります。
コア・ファイル
（恐らくは、
前回実行したときにクラッシュしコア・ダンプしたもの）
を併せて指定すると、
GDBは２つのターゲットを持ち、
メモリ・アドレスに対する要求を満足するために、
まずコア・ファイルを参照し、
次に実行ファイルを参照するという具合に、
２つのターゲットを並行して使用します
（典型的には、
これら２つのクラスのターゲットは相互に補完的です。
というのも、
コア・ファイルはプログラムが読み書き可能な変数などのメモリとマシン・ステータスのみを持ち、
実行ファイルはプログラムのテキストと初期化されたデータのみを持つからです）。
runコマンドを実行すると、
ユーザの実行ファイルはアクティブなプロセス・ターゲットにもなります。
プロセス・ターゲットがアクティブな間は、
メモリ・アドレスを要求するすべてのGDBコマンドは、
プロセス・ターゲットを参照します。
アクティブなコア・ファイル・ターゲットや
実行ファイル・ターゲットの中のアドレスは、
プロセス・ターゲットがアクティブな間は隠されます。
新しいコア・ファイル・ターゲットや実行ファイル・ターゲットを選択するには、
core-fileコマンドやexec-fileコマンドを使用します
（ファイルを指定するコマンドを参照）。
既に実行中のプロセスをターゲットとして指定するには、
attachコマンドを使用します
（既に実行中のプロセスのデバッグを参照）。
target type parameters
targetコマンド実行後RETキーを押しても、
targetコマンドは再実行されません。
help target
info targetコマンドかinfo filesコマンドを使用します
（ファイルを指定するコマンドを参照）。
help target name
set gnutarget args
set gnutargetコマンドを使用して、
ファイルのフォーマットを指定することもできます。
ほとんどのtargetコマンドとは異なり、
gnutargetにおけるtargetはマシンではなくプログラムです。
注意:
set gnutargetでファイル・フォーマットを指定するには、
実際のBFD名を知っている必要があります。
ファイルを指定するコマンドを参照してください。
show gnutarget
gnutargetがどのようなファイル・フォーマットを読むよう設定されているかを表示させるには、
show gnutargetコマンドを使用します。
gnutargetを設定していない場合、
個々のファイルのフォーマットをGDBが自動的に決定します。
この場合、
show gnutargetを実行するとThe current BDF target is "auto"と表示されます。
以下に一般的なターゲットをいくつか示します （GDBの設定により、 利用可能であったり利用不可であったりします）。
target exec program
target core filename
target remote dev
target remoteはloadコマンドもサポートしています。
これは、
スタブをターゲット・システムに持っていく方法が別にあり、
かつ、
ダウンロードによって破壊されないようなメモリ上の位置にそれを置くことができる場合にのみ役に立ちます。
target sim
target udi keyword
target amd-eb dev speed PROG
target remoteの場合と同様、
devはシリアル装置です。
speedによって回線速度を指定することができます。
PROGは、
デバッグ対象となるプログラムをPC上のDOSから見た場合の名前です。
AMD29KのEBMONプロトコルを参照してください。
target hms dev
deviceとspeedによって使用されるシリアル回線と通信速度を制御します。
GDBと日立のマイクロ・プロセッサを参照してください。
target nindy devicename
target st2000 dev speed
target vxworks machinename
target bug dev
target cpu32bug dev
target op50n dev
target w89k dev
target est dev
target rom68k dev
target array dev
target sparclite dev
target remote devです。
GDBの設定が異なれば、 利用可能なターゲットも異なるものになります。 ユーザの設定によって、 ターゲットの数は多くなったり少なくなったりします。
ターゲット・システム上で使用するバイト・オーダーを選択することができます。
set endian bigコマンドもしくはset endian littleコマンドを使用します。
実行ファイルに関連付けられているバイト・オーダーを使用するようGDBに指示するには、
set endian autoコマンドを使用します。
show endianコマンドによって、
カレントなバイト・オーダーの設定を表示させることができます。
注意:
現在のところ、
組み込みのMIPSの設定だけが、
ターゲットのバイト・オーダーの動的な選択をサポートしています。
通常の方法でGDBを実行させることのできないマシン上で実行中のプログラムをデバッグするには、
リモート・デバッグ機能を使うのが便利です。
例えば、
オペレーティング・システムのカーネルのデバッグや、
フル機能を持つデバッガを実行するのに十分な機能を持つ汎用的なオペレーティング・システムを持たないような小規模なシステムでのデバッグでは、
ユーザはリモート・デバッグ機能を使うことになるかもしれません。
GDBはその設定によっては、
特別なシリアル・インターフェイスやTCP/IPインターフェイスを持ち、
これを特定のデバッグ・ターゲット用に使用することができます。
さらに、
GDBには汎用的なシリアル・プロトコルが組み込まれており
（GDBに特有のもので、
特定のターゲット・システムに特有なものではありません）、
リモート・スタブを書けばこれを使用することができます。
リモート・スタブとは、
GDBと通信するためにリモート・システム上で動作するコードです。
GDBの設定によっては、
他のリモート・ターゲットが利用可能な場合もあります。
利用可能なリモート・ターゲットを一覧表示させるには、
help targetコマンドを使用します。
他のマシン上で実行中のプログラムをデバッグするには （targetマシンをデバッグするには）、 そのプログラムが単独で実行できるようにするために必要な通常の事前条件をすべて整える必要があります。 例えば、 Cのプログラムの場合、
次に、ユーザ・プログラムがシリアル・ポートを使って、GDBを実行中のマシン （ホスト・マシン） と通信できるように準備します。 一般的には、以下のような形になります。
gdbserverという補助プログラムを使うこともできます。
詳細については、
gdbserverプログラムの使用を参照してください。
デバッグ・スタブはリモート・マシンのアーキテクチャに固有のものです。 例えば、 SPARCボード上のプログラムをデバッグするには`sparc-stub.c'を使います。 以下に実際に使えるスタブを列挙します。 これらは、 GDBと一緒に配布されています。
i386-stub.c
m68k-stub.c
sh-stub.c
sparc-stub.c
sparcl-stub.c
GDBとともに配布されるREADMEファイルには、 新しく追加された他のスタブのことが記されているかもしれません。
各ユーザのアーキテクチャ用のデバッグ・スタブは、 ３つのサブルーチンを提供します。
set_debug_traps
handle_exceptionが実行されるよう設定します。
ユーザ・プログラムは、
その先頭近くでこのサブルーチンを明示的に呼ばなければなりません。
handle_exception
handle_exceptionが実行されるよう設定されます。
ユーザ・プログラムが実行中に
（例えば、ブレイクポイントで）
停止すると、
handle_exceptionが制御権を獲得し、
ホスト・マシン上のGDBとの通信を行います。
これが、
通信プロトコルが実装されている部分です。
handle_exceptionはターゲット・マシン上でGDBの代理として機能します。
それはまず、
ユーザ・プログラムの状態に関する情報を要約して送ることから始めます。
次に、
処理を継続して、
GDBが必要とする情報を入手し転送します。
これは、
ユーザがユーザ・プログラムの実行を再開させるようなGDBコマンドを実行するまで続きます。
そのようなコマンドが実行されると、
handle_exceptionは制御をターゲット・マシン上のユーザ・コードに戻します。
breakpoint
handle_exceptionに、
つまり事実上GDBに渡されます。
マシンによっては、
シリアル・ポートから文字を受け取るだけでトラップが発生することもあります。
このような場合には、
ユーザ・プログラム自身からbreakpointを呼び出す必要はなく、
ホストのGDBセッションから`target remote'を実行するだけで制御を得ることができます。
これらのどのケースにも該当しない場合、
あるいは、
デバッグ・セッションの開始箇所としてあらかじめ定義されたところでユーザ・プログラムが停止することを単に確実にしたいのであれば、
breakpointを呼び出してください。
GDBとともに配布されるデバッグ用スタブは特定のチップのアーキテクチャ用にセットアップされたものですが、 デバッグのターゲット・マシンのそれ以外の部分に関する情報は持っていません。 まず最初に、 どのようにしてシリアル・ポートと通信するかをスタブに教えてやる必要があります。
int getDebugChar()
getcharと同一かもしれません。
これら２つを区別したい場合を考慮して、
異なる名前が使われています。
void putDebugChar(int)
putcharと同一かもしれません。
これら２つを区別したい場合を考慮して、
異なる名前が使われています。
実行中のユーザ・プログラムをGDBが停止できるようにしたいのであれば、
割り込み駆動型のシリアル・ドライバを使用して、
^C
（control-C文字、
あるいは`\003'）
を受信した時に停止するよう設定する必要があります。
GDBはこの文字を使って、
リモート・システムに対して停止するよう通知します。
デバッグ・ターゲットが適切なステータス情報をGDBに対して返せるようにするためには、
おそらく標準のスタブを変更する必要があるでしょう。
最も美しくなく、
しかし最も迅速にこれを実現する方法は、
ブレイクポイント命令を実行することです
（この方法が「美しくない」のは、
GDBがSIGINTではなくSIGTRAPを発生させる点にあります）。
ユーザが提供する必要のある他のルーチンには、
以下のようなものがあります。
void exceptionHandler (int exception_number, void *exception_address)
exceptionHandlerの助けを借りなくても自分で割り込みをマスクすることができます。
void flush_i_cache()
また、次のライブラリ・ルーチンが使用可能であることを確かめなければなりません。
void *memset(void *, int, int)
memsetです。
フリーのlibc.aを持っていれば、
そこにmemsetがあります。
フリーのlibc.aがなければ、
memsetをハードウェアの供給元から入手するか、自分で書く必要があります。
GNU Cコンパイラを使っていないのであれば、
他の標準ライブラリ・サブルーチンも必要になるかもしれません。
これは、
スタブによって異なりますが、
一般的に言ってスタブは、
gccがインライン・コードとして生成する共通ライブラリ・サブルーチンのいくつかを使用する可能性があります。
要約すると、ユーザ・プログラムがデバッグできるようになると、以下の手順に従わなければなりません。
getDebugChar,putDebugChar,flush_i_cache,memset,exceptionHandler.
set_debug_traps(); breakpoint();
exceptionHookという変数を提供する必要があります。
通常は、
以下のように使います。
void (*exceptionHook)() = 0;
set_debug_trapsが呼ばれる前に、
ユーザがこの変数をユーザ・プログラム内のある関数を指すよう設定すると、
トラップ
（例えば、
バス・エラー）
で停止した後にGDBが処理を継続実行する時に、
その関数が呼び出されます。
exceptionHookによって指される関数は１つの引数付きで呼び出されます。
それはintint型の例外番号です。
target remoteコマンドを使って通信を確立します。
引数には、
シリアル回線に接続された装置名あるいは
（通常はターゲットとの間にシリアル回線を持つ端末サーバの）
TCPポートを指定することで、
どのようにしてターゲット・マシンと通信するかを指定します。
例えば、
`/dev/ttyb'という名前の装置に接続されているシリアル回線を使うには、
target remote /dev/ttybとします。 TCPコネクションを使うには、
host:portという形式の引数を使用します。
例えば、
manyfarmsという名前の端末サーバのポート2828に接続するには、
target remote manyfarms:2828とします。
ここまでくると、
データの値の調査、
変更、
リモート・プログラムのステップ実行、
継続実行に通常使用するすべてのコマンドを使用することができます。
リモート・プログラムの実行を再開し、
そのデバッグを止めるにはdetachコマンドを使います。
GDBがリモート・プログラムを待っている時にはいつでも、
割り込み文字
（多くの場合
C-C）
を入力すると、
GDBはそのプログラムを停止しようとします。
これは成功することも失敗することもありますが、
その成否は、
リモート・システムのハードウェアやシリアル・ドライバにも依存します。
割り込み文字を再度入力すると、
GDBは以下のプロンプトを表示します。
Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n)
ここでyを入力すると、 GDBはリモート・デバッグ・セッションを破棄します （後になって再実行したくなった場合には、 接続するために`target remote'を再度使用します）。 nを入力すると、 GDBは再び待ち状態になります。
GDBとともに提供されるスタブ・ファイルはターゲット側の通信プロトコルを実装します。 そしてGDB側の通信プロトコルは、 GDBのソース・ファイル`remote.c'に実装されています。 通常ユーザは、 これらのサブルーチンに通信処理を任せて、 詳細を無視することができます （ユーザが独自のスタブ・ファイルを作成する時でも詳細を無視して、 既存のスタブ・ファイルを元にして始めることができます。 `sparc-stub.c'が最もよく整理されており、 したがって最も読みやすくなっています）。 しかし、 場合によっては、 プロトコルについて何かを知る必要が出てくることもあるでしょう。 例えば、 ターゲット・マシンに１つしかシリアル・ポートがなく、 ユーザ・プログラムがGDB宛のパケットを検出した時に何か特別なことをするようにしたい場合です。 （単一文字による確認メッセージを除く） すべてのGDBコマンドとそれに対する応答は、 チェックサムを含むパケットとして送信されます。 パケットは、 文字`$'で始まり、 文字`#'に２桁のチェックサム値が続いて終ります。
$packet info#checksum
ここで、 checksumはpacket infoのすべての文字の値を合計したものを256で割った余りとして計算されます。 ホスト・マシンもしくはターゲット・マシンがパケットを受信した時、最初に期待される応答は確認メッセージです。 これは単一文字で、 （パッケージが正しく受信されたことを示す） `+'もしくは （再送要求を示す） `-'です。 ホスト （GDB） がコマンドを送信し、 ターゲット （ユーザ・プログラムに組み込まれたデバッグ・スタブ） が応答としてデータを送信します。 ターゲットは、ユーザ・プログラムが停止した時にも、データを送信します。 コマンド・パケットは最初の文字で区別されます。 最初の文字がコマンドの種類を表します。 以下に、 現在サポートされているコマンドをいくつか列挙します （コマンドの完全なリストについては`gdb/remote.c'を参照）。
g
G
maddr,count
Maddr,count:...
c
caddr
s
saddr
k
?
T
シリアル接続に問題がある場合には、
set remotedebugコマンドを使うことができます。
これにより、
GDBはシリアル回線経由でリモート・マシンとの間で送受信したすべてのパケットを報告するようになります。
パケット・デバッグ用の情報はGDBの標準出力ストリームに表示されます。
set remotedebug offによってこの設定が解除され、
show remotedebugによって現在の設定が表示されます。
gdbserverプログラムの使用
gdbserverはUNIX系のシステム用の制御プログラムで、
これにより、
通常のデバッグ用スタブをリンクすることなく、
target remoteコマンドによって、
ユーザ・プログラムをリモートのGDBに接続することができます。
gdbserverはデバッグ用スタブに完全に取って代わるものではありません。
というのは、
gdbserverはGDBが必要とするのと同様のオペレーティング・システムの機能を基本的には必要とするからです。
実際、
リモートのGDBと接続するためにgdbserverを実行できるシステムであれば、
GDBをローカルに実行することも可能です。
それでも、
gdbserverはGDBと比較するとずっとサイズが小さいので、
便利なことがあります。
また、
gdbserverの移植はGDB全体の移植よりも簡単なので、
gdbserverを使うことで、
新しいシステムでの作業をより早く開始することができます、
最後に、
リアル・タイム・システムの開発をしている場合、
リアル・タイムな操作に関わるトレードオフのために、
例えばクロス・コンパイルなどによって他のシステム上で可能な限り多くの開発作業を行ったほうがより便利であるということがあるでしょう。
デバッグ作業に関しても、
gdbserverを使うことで同様の選択を行うことができます。
GDBとgdbserverはシリアル回線もしくはTCP接続を介して、
標準的なGDBリモート・シリアル・プロトコルによって通信します。
gdbserverはユーザ・プログラムのシンボル・テーブルを必要とはしませんので、
スペースの節約が必要であれば、
プログラムをストリップすることができます。
ホスト・システム上のGDBがシンボルに関するすべての処理を実行します。
サーバを使うには、GDBとの通信方法、
ユーザ・プログラムの名前、
ユーザ・プログラムへの引数を教えてやる必要があります。
構文は、
以下のとおりです。
target> gdbserver comm program [ args ... ]commは （シリアル回線を使うための） 装置名か、 もしくは、 TCPのホスト名とポート番号です。 例えば、 `foo.txt'という引数でEmacsをデバッグし、 シリアル・ポート`/dev/com1'経由でGDBと通信するには、 以下のように実行します。
target> gdbserver /dev/com1 emacs foo.txt
gdbserverは、
ホスト側のGDBが通信してくるのを受動的に待ちます。
シリアル回線の代わりにTCP接続を使うには、
以下のようにします。
target> gdbserver host:2345 emacs foo.txt前の例との唯一の違いは第１引数です。 これは、 ホストのGDBとTCPによって接続することを指定しています。 `host:2345'は
gdbserverがマシン`host'からローカルのTCPポート2345へのTCP接続を期待していることを意味します
（現在のバージョンでは、
`host'の部分は無視されます）。
ターゲット・システム上で既に使われているTCPポートでなければ、任意の番号をポート番号として選択できます
（例えば、
23はtelnetに予約されています）
(4)。
ここで指定したのと同じポート番号を、
GDBのtarget remoteコマンドで使わなければなりません。
target remoteコマンドによってgdbserverとの通信を確立します。
引数には、
装置名
（通常は`/dev/ttyb'のようなシリアル装置）
もしくはhost:PORTという形式でのTCPポート記述子を指定します。
例えば、
(gdb) target remote /dev/ttybでは、 シリアル回線`/dev/ttyb'を介してサーバと通信しますし、
(gdb) target remote the-target:2345では、 ホスト`the-target'上のポート2345に対するTCP接続によってサーバと通信します。 TCP接続を使う場合には、
target remoteコマンドを実行する前にgdbserverを起動しておかなければなりません。
そうしないと、エラーになります。
エラー・テキストの内容はホスト・システムによって異なりますが、
通常は`Connection refused'のような内容です。
gdbserve.nlmプログラムの使用
gdbserve.nlmはNetWareシステムでの制御プログラムであり、
これによりtarget remoteコマンドでユーザ・プログラムをリモートのGDBに接続することができます。
GDBとgdbserve.nlmは標準のGDBリモート・シリアル・プロトコルを使って、
シリアル回線経由で通信します。
gdbserve.nlmはユーザ・プログラムのシンボル・テーブルを必要とはしませんので、
スペースの節約が必要であれば、
プログラムをストリップすることができます。
ホスト・システム上のGDBがシンボルに関わるすべての処理を実行します。
サーバを使うには、
GDBとの通信方法、
ユーザ・プログラムの名前、
ユーザ・プログラムの引数を教えてやる必要があります。
構文は、
以下のとおりです。
load gdbserve [ BOARD=board ] [ PORT=port ]
[ BAUD=baud ] program [ args ... ]
boardとportがシリアル回線を指定します。
baudは接続に使われるボーレートを指定します。
portとnodeのデフォルト値は0、
baudのデフォルト値は9600 bpsです。
例えば、
`foo.txt'という引数でEmacsをデバッグし、
シリアル・ポート番号2、
ボード1経由で19200 bpsの接続でGDBと通信するには、
以下のように実行します。
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
target remoteコマンドによって
gdbserve.nlmとの通信を確立します。
引数には、
装置名
（通常は`/dev/ttyb'のようなシリアル装置）
を指定します。
例えば、
(gdb) target remote /dev/ttybは、 シリアル回線`/dev/ttyb'を介してサーバと通信します。
NindyはIntel 960ターゲット・システム用のROM Monitorプログラムです。 Nindyを使ってリモートのIntel 960を制御するようGDBが設定されている場合、 いくつかの方法によってGDBに960との接続方法を教えることができます。
targetコマンドを使う方法
（ターゲットを管理するコマンドを参照してください）
コマンドライン・オプションを一切使わずにgdbを起動すると、
通常のGDBプロンプトが表示される前に、
どのシリアル・ポートを使うのかを入力するよう促されます。
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
このプロンプトに対して使いたいシリアル・ポートを示すサフィックスを
（`/dev/tty'に続けて）
入力します。
もしそうしたいのであれば、
プロンプトに空行で答えることによって、
Nindyとの接続を確立せずに起動することもできます。
この場合、
後にNindyと接続したい時にはtargetコマンドを使います
（ターゲットを管理するコマンドを参照）。
接続されたNindy-960とのGDBセッションを開始するためのオプションを以下に示します。
-r port
tty固有の一意なサフィックス
（例：`-r a'）
のいずれによっても指定することができます。
GDB
port
-O
注意：`-O'を指定したにもかかわらず、 実際にはより新しいプロトコルを期待しているターゲット・システムに接続しようとした場合、 あたかも通信速度の不一致によって接続が失敗したかのように見えます。 GDBは異なる回線速度によって再接続を繰り返し試みます。 割り込みによって、この処理を中断することができます。
-brk
BREAK信号を送信するようGDBに対して指定します。
注意：多くのターゲット・システムは、 このオプションが必要とするハードウェアを備えていません。 このオプションは、 ２、 ３のボードでしか機能しません。
標準の`-b'オプションによってシリアル・ポート上で使用される回線速度を制御します。
reset
GDBは、
a29kプロセッサ・ファミリをデバッグするためのAMD UDI
（Universal Debugger Interface）
プロトコルをサポートします。
MiniMONモニタを実行するAMDターゲットでこの設定を使うには、
AMD社から無料で入手可能なMONTIPプログラムが必要になります。
また、
AMD社から入手可能なUDI準拠のa29kシミュレータ・プログラムISSTIPとともにGDBを使うこともできます。
target udi keyword
AMD社はPC組み込み用の29K開発ボードを、
DOS上で動作するEBMONというモニタ・プログラムと一緒に配布しています。
この開発システムは、
省略してEB29Kと呼ばれます。
UNIXシステム上のGDBを使って、
EB29Kボード上でプログラムを実行するには、
まず
（EB29Kを組み込んだ）
PCとUNIXシステムのシリアル・ポートの間をシリアル回線で接続しなければなりません。
以下の節では、
PCの`COM1'ポートとUNIXシステムの`/dev/ttya'との間をケーブルで接続してあるものと仮定します。
次に、 PC上のDOSで以下のようなことを行うことによって、 PCのポートをセットアップします。
C:\> MODE com1:9600,n,8,1,none
MS DOS 4.0上で実行されているこの例では、 通信速度を9600 bps、 パリティ・ビットなし、 データ・ビットを8ビット、 ストップ・ビットを1ビット、 リトライなしに設定しています。 UNIX側を設定する際には、 同一の通信パラメータを使わなければなりません。 シリアル回線のUNIX側にPCの制御権を与えるには、 DOSコンソール上で以下のように実行します。
C:\> CTTY com1
（後に、
DOSコンソールに制御を戻したい時には、
CTTY conコマンドを使うことができます
---ただし、
制御権を持っている装置から、
ここでの例では`COM1'に接続されているシリアル回線を通して、
このコマンドを送信する必要があります）。
UNIXのホストからは、
PCと通信するのにtipやcuのような通信プログラムを使います。
例えば、
cu -s 9600 -l /dev/ttya
ここで示されているcuオプションはそれぞれ、
使用する回線速度とシリアル・ポートを指定しています。
tipコマンドを使った場合は、
コマンドラインは以下のようなものになるでしょう。
tip -9600 /dev/ttya
ここでtipへの引数として指定した`/dev/ttya'の部分には、
ユーザのシステムでは異なる名前を指定する必要があるかもしれません。
使用するポートを含む通信パラメータは、
"remote"記述ファイルにおいてtipコマンドへの引数と関連付けられます。
通常このファイルは、
システム・テーブル`/etc/remote'です。
tip接続、
もしくはcu接続を使用して、
DOSの作業ディレクトリをユーザの
29Kプログラムがあるディレクトリに変更し、
PCプログラムEBMON
（AMD社からボードとともに提供されるEB29K制御プログラム）
を起動します。
以下に示すのによく似た、
EBMONプロンプト`#'で終わるEBMONの初期画面が表示される筈です。
C:\> G: G:\> CD \usr\joe\work29k G:\USR\JOE\WORK29K> EBMON Am29000 PC Coprocessor Board Monitor, version 3.0-18 Copyright 1990 Advanced Micro Devices, Inc. Written by Gibbons and Associates, Inc. Enter '?' or 'H' for help PC Coprocessor Type = EB29K I/O Base = 0x208 Memory Base = 0xd0000 Data Memory Size = 2048KB Available I-RAM Range = 0x8000 to 0x1fffff Available D-RAM Range = 0x80002000 to 0x801fffff PageSize = 0x400 Register Stack Size = 0x800 Memory Stack Size = 0x1800 CPU PRL = 0x3 Am29027 Available = No Byte Write Available = Yes # ~.
続いて、
cuプログラムもしくはtipプログラムを終了させます
（上の例では、
EBMONプロンプトにおいて~.を入力することで終了させています）。
EBMONは、
GDBが制御権を獲得できる状態で、
実行を継続します。
この例では、
PCとUNIXシステム上に同一の29Kプログラムが確実に存在するようにするのに、
恐らく最も便利な方法を使うことを仮定しました。
それは、
PC/NFSによる接続で、
UNIXホストのファイル・システムの１つをPCのG:ドライブとする方法です。
PC/NFSもしくは、
２つのシステム間を接続する類似の方法がない場合、
フロッピ・ディスクによる転送など、
UNIXシステムからPCへ29Kプログラムを転送するための他の手段を準備する必要があります。
GDBはシリアル回線経由でそれをダウンロードすることはしません。
最後に、
cdでUNIXシステム上で29Kプログラムが存在するディレクトリに移動し、
29Kプログラムの名前を引数に指定してGDBを起動します。
cd /usr/joe/work29k gdb myfoo
これでtargetコマンドが使えるようになります。
target amd-eb /dev/ttya 9600 MYFOO
この例では、
ユーザ・プログラムは`myfoo'と呼ばれるファイルにあるものと仮定しています。
target amd-ebに対して最後の引数として指定するファイル名は、
DOS上でのプログラム名でなければならない点に注意してください。
この例では単にMYFOOとなっていますが、
DOSのパス名を含むこともできますし、
転送メカニズムによっては、
UNIX側での名前とは似ても似つかないものになるかもしれません。
ここまでくると、
好きなようにブレイクポイントを設定することができます。
29Kボード上でのプログラムの実行を監視する準備が整えば、
GDBのrunコマンドを使います。
リモート・プログラムのデバッグを停止するには、
GDBのdetachコマンドを使います。
PCの制御をPCコンソールに戻すには、GDBセッションが終了した後に、EBMON
EBMONにアタッチするために、
もう一度tipもしくはcuを使います。
その後、
qコマンドによってEBMONをシャットダウンし、
DOSのコマンドライン・インタープリタに制御を戻します。
CTTY conと入力して、
入力されたコマンドがメインのDOSコンソールによって受け取られるようにし、
~.を入力してtipもしくはcuを終了させます。
target amd-ebコマンドは、
接続に関わる問題のデバッグを支援するため、
カレントな作業ディレクトリに`eb.log'というファイルを作成します。
`eb.log'は、
EBMONに送信されたコマンドのエコーを含む、
EBMONからのすべての出力を記録します。
別のウィンドウ内でこのファイルに対して`tail -f'を実行すると、
EBMONに関わる問題やPC側での予期せぬイベントを理解する助けになることがよくあります。
ST2000をホスト・システムに接続する方法については、 製造元のマニュアルを参照してください。 ST2000が物理的に接続されれば、 それをデバッグ環境として確立するには、以下を実行します。
target st2000 dev speed
ここで、
devは通常、
シリアル回線によってST2000と接続される`/dev/ttya'のようなシリアル装置の名前です。
代わりに、
hostname:portnumberという構文を使って
（例えば、端末多重化装置経由で接続されたシリアル回線への）
TCP接続としてdevを指定することもできます。
このターゲットに対して、
loadコマンドとattachコマンドは定義されていません。
普段スタンドアロンで操作しているのと同様に、
ST2000にユーザ・プログラムをロードしなければなりません。
GDBは
（シンボルのような）
デバッグ用の情報を、
ホスト・コンピュータ上にある別のデバッグ・バージョンのプログラムから読みとります。
ST2000での作業を支援するため、
以下の補助的なGDBコマンドが利用可能になっています。
st2000 command
connect
GDBを使用することで、
UNIXのホストから、
ネットワークに接続されたVxWorks端末上でタスクを起動しデバッグすることができます。
VxWorksシェルから起動され、
既に実行中の状態のタスクもデバッグできます。
GDBはUNIXホスト上で実行されるコードとVxWorksターゲット上で実行されるコードの両方を使います。
gdbプログラムはUNIXホスト上にインストールされ実行されます
（ホスト上のプログラムをデバッグするのに使うGDBと区別するために、
vxgdbという名前でインストールされることもあります）。
VxWorks-timeout args
vxworks-timeoutオプションをサポートしています。
このオプションはユーザによってセットされるもので、
argsはGDBがRPCの応答を待つ秒数を表します。
実際のVxWorksターゲットが速度の遅いソフトウェア・シミュレータであったり、
帯域の小さいネットワーク回線を介して遠距離にある場合などに使うとよいでしょう。
以下に示すVxWorksとの接続に関する情報は、
このマニュアルの製作時における最新の情報です。
新しくリリースされたVxWorksでは、異なる手順を使うかもしれません。
GDBをVxWorksで使うためには、
VxWorksカーネルを再構築して、
VxWorksライブラリ`rdb.a'の中にリモート・デバッグ用のインターフェイス・ルーチンを組み込む必要があります。
そのためには、
VxWorksのコンフィギュレーション・ファイル`configAll.h'の中でINCLUDE_RDBを定義して、
VxWorksカーネルを再構築します。
この結果として生成されるカーネルには`rdb.a'が含まれ、
VxWorksの起動時にソース・デバッグ用のタスクtRdbTaskが起動されます。
VxWorksの設定や再構築に関する詳細については、
製造元のマニュアルを参照してください。
VxWorksシステムへの`rdb.a'の組み込みが終わり、
UNIXの実行モジュール検索パスにGDBの存在するパスを加えれば、
GDBを実行するための準備は完了です。
UNIXホストからgdb
（インストールの方法によってはvxgdb）
を実行します。
GDBが起動し、以下のプロンプトを表示します。
(vxgdb)
GDBのtargetコマンドによって、
ネットワーク上のVxWorksターゲットに接続します。
ttというホスト名を持つターゲットに接続するには、
以下のようにします。
(vxgdb) target vxworks tt
GDBは以下のようなメッセージを表示します。
Attaching remote machine across net... Connected to tt.
続いてGDBは、 最後にVxWorksターゲットが起動された時点以降にロードされたオブジェクト・モジュールのシンボル・テーブルを読み込もうと試みます。 GDBはこれらのファイルを、 コマンドの検索パスにリストされているディレクトリを検索することで見つけます （ユーザ・プログラムの環境を参照）。 オブジェクト・ファイルを見つけることができない場合には、 以下のようなメッセージを表示します。
prog.o: No such file or directory.
このような場合には、
GDBのpathコマンドによって適切なディレクトリを検索パスに加え、
再度targetコマンドを実行します。
VxWorksターゲットに接続済みで、
まだロードされていないオブジェクトをデバッグしたい場合には、
GDBのloadコマンドを使ってUNIXからVxWorksへ追加的にファイルをダウンロードすることができます。
loadコマンドの引数として指定されたオブジェクト・ファイルは、
実際には２回オープンされます。
まず、
コードをダウンロードするためにVxWorksターゲットによってオープンされ、
次にシンボル・テーブルを読み込むためにGDBによってオープンされます。
２つのシステム上のカレントな作業ディレクトリが異なると、
これは問題を引きおこします。
両方のシステムが同一のファイル・システムをNFSマウントしているのであれば、
絶対パスを使うことで問題を回避することができます。
これ以外の場合は、
両方のシステムで作業ディレクトリをオブジェクト・ファイルが存在するディレクトリに設定し、
パスを一切使わずにその名前だけでファイルを参照するのが、
最も簡単でしょう。
例えば、プログラム
`prog.o'がVxWorksでは`vxpath/vw/demo/rdb'に存在し、
ホストでは`hostpath/vw/demo/rdb'に存在するとしましょう。
このプログラムをロードするには、
VxWorks上で以下を実行します。
-> cd "vxpath/vw/demo/rdb"
次にGDB上で、 以下を実行します。
(vxgdb) cd hostpath/vw/demo/rdb (vxgdb) load prog.o
GDBは次のような応答を表示します。
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
ソース・ファイルを編集し再コンパイルした後、
loadコマンドを使ってオブジェクト・モジュールを再ロードすることもできます。
ただし、
これを行うと、
GDBはその時点で定義されているすべてのブレイクポイント、
自動表示設定、
コンビニエンス変数を削除し、
値ヒストリを初期化してしまいますので、
注意してください
（これは、
ターゲット・システムのシンボル・テーブルを参照するデバッガのデータ構造の完全性を保つために必要です）。
以下のようにattachコマンドを使うことで、
既存のタスクにアタッチすることも可能です。
(vxgdb) attach task
ここでtaskはVxWorksの16進数のタスクIDです。 アタッチする時に、 タスクは実行中であってもサスペンドされていても構いません。 実行中であったタスクは、 アタッチされた時点でサスペンドされます。
開発者はGDBを使うことにより、
Sparcletターゲット上で実行中のタスクをUnixホストからデバッグできるようになります。
GDBは、
Unixホスト上でもSparcletターゲット上でも動作するコードを使用します。
gdbプログラムはUnixホスト上にインストールされ実行されます。
timeout args
remotetimeoutをサポートするようになりました。
このオプションはユーザによって設定されるもので、
argsはGDBが応答を待つ秒数を表します。
デバッグ用にコンパイルする際には、 デバッグ情報を得るために"-g"オプションを、 また、 ターゲット上でロードしたい位置にプログラムを再配置するために"-Ttext"オプションを指定します。 セクションのサイズを縮小するために"-n"、 もしくは、 "-N"オプションを加えるのも良いでしょう。
sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N
アドレスが意図したものと一致しているかどうかを検証するのにobjdumpを使うことができます。
sparclet-aout-objdump --headers --syms prog
GDBを見つけるためのUnix実行サーチ・パスを設定すれば、
GDBを実行するための準備は完了です。
Unixホストからgdb
（インストールの方法によっては、
sparclet-aout-gdb）
を実行します。
GDBが起動されて、
プロンプトを表示します。
(gdbslet)
GDBのfileコマンドによってデバッグするプログラムを選択することができます。
(gdbslet) file prog
このコマンドを実行すると、 GDBは`prog'のシンボル・テーブルを読み込もうとします。 GDBは、 コマンド・サーチ・パスに含まれるディレクトリを探索することによって、 そのファイルを見つけます。 そのファイルがデバッグ情報付き （オプション"-g"） でコンパイルされた場合、 ソース・ファイルも探されます。 GDBは、 ディレクトリ・サーチ・パス （ユーザ・プログラムの環境を参照） に含まれるディレクトリを探索することによって、 そのソース・ファイルを見つけます。 ファイルが見つからない場合には、 次のようなメッセージを表示します。
prog: No such file or directory.
このメッセージが表示された場合には、
GDBのpathコマンドとdirコマンドを使って適切なディレクトリをサーチ・パスに加えてから、
targetコマンドを再実行します。
GDBのtargetコマンドによってSparcletターゲットへ接続することができます。
シリアル・ポート"ttya"でターゲットに接続するには、
以下のように入力します。
(gdbslet) target sparclet /dev/ttya Remote target sparclet connected to /dev/ttya main () at ../prog.c:3
GDBは以下のようなメッセージを表示します。
Connected to ttya.
Sparcletターゲットへの接続が完了すると、
GDBのloadコマンドを使って、
ホストからターゲットへファイルをダウンロードすることができます。
ファイル名とロード・オフセットは、
loadコマンドへの引数として渡さなければなりません。
ファイル形式はaoutですので、
プログラムはその開始アドレスにロードされなければなりません。
開始アドレスの値を知るにはobjdumpを使うことができます。
ロード・オフセットとは、
ファイルの個々のセクションのVMA（仮想メモリ・アドレス）に加算されるオフセットのことです。
例えば、
プログラム`prog'が、
textセクションのアドレス0x12010000、
dataセクションのアドレス0x12010160、
bssセクションのアドレス0x12010170としてリンクされているとすると、
GDBでは以下のように入力します。
(gdbslet) load prog 0x12010000 Loading section .text, size 0xdb0 vma 0x12010000
プログラムがリンクされたアドレスとは異なるアドレスにコードがロードされた場合、
どこにシンボル・テーブルをマップするかをGDBに通知するためにsectionコマンドとadd-symbol-fileコマンドを使う必要があるかもしれません。
以上により、
GDBの実行制御コマンドb、
step、
run等を使ってタスクのデバッグを開始することができます。
コマンドの一覧については、
GDBマニュアルを参照してください。
(gdbslet) b main Breakpoint 1 at 0x12010000: file prog.c, line 3. (gdbslet) run Starting program: prog Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3 3 char *symarg = 0; (gdbslet) step 4 char *execarg = "hello!"; (gdbslet)
日立のSH、 H8/300、 H8/500と通信するためには、 GDBは以下の情報を知っている必要があります。
シリアル装置を明示的に指定する必要があるのであれば、
そのために特別にあるgdbの`device port'コマンドを使用します。
portのデフォルトは、
ホスト上で最初に利用可能なポートです。
これはUNIXホスト上でのみ必要であり、
そこでは典型的には`/dev/ttya'という名前になります。
gdbには通信速度を設定するための特別なコマンド`speed bps'があります。
このコマンドもまた
UNIXホストからのみ使用されるものです。
DOSホストでは通常どおり、
GDBからではなくDOSのmodeコマンドによって回線速度を設定します
（例えば、
9600 bpsの接続を確立するには`mode com2:9600,n,8,1,p'のように実行します）。
`device'コマンドと`speed'コマンドは、
日立マイクロ・プロセッサ・プログラムのデバッグにUNIXホストを使う場合のみ利用可能です。
DOSホストを使う場合、
GDBは、
PCシリアル・ポート経由で開発ボードと通信するのに
asynctsrと呼ばれる補助的な常駐プログラムに依存します。
DOS側でシリアル・ポートの設定をする場合にも
DOSのmodeコマンドを使わなければなりません。
E7000インサーキット・エミュレータを使って、 日立SHもしくはH8/300H用のコードを開発することができます。 `target e7000'コマンドを以下のいずれかの形式で使って、 GDBをE7000に接続してください。
target e7000 port speed
target e7000 hostname
telnetを使います。
いくつかのGDBコマンドは、 H8/300もしくはH8/500用に設定された場合にのみ利用可能です。
set machine h8300
set machine h8300h
set memory mod
show memory
small、
big、
medium、
compactのいずれかです。
GDBは、 MIPSのリモート・デバッグ用のプロトコルを使って、 シリアル回線に接続されたMIPSボードと通信することができます。 これは、 GDBを`--target=mips-idt-ecoff'によって設定すると、 利用することができます。 ターゲット・ボードとの接続を指定するには、 以下のGDBコマンドを使用します。
target mips port
gdbを起動します。
ボードに接続するには、
`target mips port'コマンドを使用します。
ここで、
portはボードに接続されているシリアル・ポートの名前です。
プログラムがまだボードにダウンロードされていないのであれば、
loadコマンドを使ってダウンロードすることができます。
その後、
通常使用できるすべてのGDBコマンドを使うことができます。
例えば、
以下の手順では、
シリアル・ポートを介してターゲット・ボードに接続し、
デバッガによってprogと呼ばれるプログラムをロードし、
実行します。
host$ gdb prog GDB is free software and ... (gdb) target mips /dev/ttyb (gdb) load prog (gdb) run
target mips hostname:portnumber
target pmon port
target ddb port
target lsi port
GDBはMIPSターゲットに対して以下の特別なコマンドもサポートしています。
set processor args
show processor
set processorコマンドを使ってMIPSプロセッサの種類を設定します。
例えば、
set processor r3041はGDBに対して、
3041チップでのみ有効なCPOレジスタを使うことを通知します。
GDBが使っているMIPSプロセッサの種類を知るにはshow processorコマンドを使います。
GDBが使っているレジスタを知るにはinfo regコマンドを使います。
set mipsfpu double
set mipsfpu single
set mipsfpu none
show mipsfpu
mipsfpu変数に関する設定を`show mipsfpu'によって問い合わせることができます。
set remotedebug n
show remotedebug
remotedebug変数を設定することによって、
ボードとの通信に関するいくつかのデバッグ用の情報を見ることができます。
`set remotedebug 1'によって値1を設定すると、
すべてのパケットが表示されます。
値を2に設定すると、
すべての文字が表示されます。
いつでも`show remotedebug'によってカレントな値を調べることができます。
set timeout seconds
set retransmit-timeout seconds
show timeout
show retransmit-timeout
set timeout secondsコマンドで制御することができます。
デフォルトは５秒です。
同様に、
パケットに対する確認
（ACK）
を待っている状態でのタイムアウト時間を、
set retransmit-timeout secondsコマンドで制御することができます。
デフォルトは３秒です。
それぞれの値をshow timeoutとshow retransmit-timeoutで調べることができます
（どちらのコマンドもGDBが`--target=mips-idt-ecoff'用に設定されている場合のみ使用可能です）。
set timeoutで設定されたタイムアウト時間は、
ユーザ・プログラムが停止するのをGDBが待っている間は適用されません。
この場合には、
GDBは永遠に待ち続けます。
これは、
プログラムが停止するまでにどの程度長く実行を継続するのかを知る方法がないからです。
いくつかの設定においては、 ユーザ・プログラムをデバッグする際にハードウェアCPUの代わりに使えるCPUシミュレータをGDBは持っています。 現在のところシミュレータは、 GDBがZilog Z8000もしくは日立マイクロ・プロセッサをデバッグ・ターゲットとして設定されている場合のみ、 利用可能です。 Z8000系については、 `target sim'によりZ8002 （Z8000のセグメントを持たない変種） もしくはZ8001 （セグメントを持つ変種） をシミュレートします。 シミュレータは、 オブジェクト・コードを調べることで、 どちらのアーキテクチャが適切であるかを認識します。
target sim
このターゲットを指定した後、
ホスト・コンピュータ上のプログラムをデバッグするのと同様の方法で、
シミュレートされたCPU用のプログラムをデバッグすることができます。
新しいプログラムのイメージをロードするには
fileコマンドを使い、
ユーザ・プログラムを実行するにはrunコマンドを使う、
という具合です。
このデバッグ・ターゲットでは、通常のマシン・レジスタ
（info reg を参照）
がすべて利用可能であるだけでなく、
特別な名前を持つレジスタとして、
さらに３つの情報を提供します。
cycles
insts
time
これらの変数はGDBの式の中で通例どおりに参照することができます。 例えば、 `b fputc if $cycles>5000'は、 シミュレートされたクロック・ティックが最低5,000回発生した後に停止するような条件付きブレイクポイントを設定します。