GDBコマンドのほとんどすべては、 このデバッガのネイティブ版、 クロス版のすべてにおいて利用可能ですが、 これには例外もあります。 この章では、 特定のコンフィギュレーションにおいてのみ利用可能なことについて説明します。
コンフィギュレーションには3つの主要なカテゴリがあります。 ネイティブ・コンフィギュレーションにおいては、 ホストとターゲットは同一です。 組み込みオペレーティング・システムのコンフィギュレーションにおいても、 いくつかの異なるプロセッサ・アーキテクチャにおいては、 通常はホストとターゲットが同一です。 一方、 組み込みプロセッサ（ボード）のコンフィギュレーションでは、 これらは極めて異なるものとなります。
このセクションでは、 特定のネイティブ・コンフィギュレーションに固有な詳細について説明します。
HP-UXシステム上においてドル記号で始まる関数名や変数名を指定すると、 GDBは、 コンビニエンス変数を探す前に、 ユーザ名やシステム名を探します。
SVR4の多くのバージョンは、
`/proc'と呼ばれる便利な機能を提供しています。
これは、
ファイル・システム関連のサブルーチンを使用して、
実行中プロセスのイメージを調べるのに使用することができます。
GDBが、
この機能を持つオペレーティング・システム用に構成されていれば、
info procコマンドを使用することで、
ユーザ・プログラムを実行しているプロセスに関するいくつかの情報を知ることができます。
info procは、
procfsコードを持つSVR4システム上でのみ機能します。
これには例えば、
OSF/1（Digital Unix）、
Solaris、
Irix、
Unixware
が含まれますが、
HP-UXやLinuxは含まれません。
info proc
info proc mappings
info proc times
info proc id
info proc status
info proc all
このセクションでは、 いくつかの異なるアーキテクチャに対して利用可能な組み込みオペレーティング・システムのデバッグに関係するコンフィギュレーションについて説明します。
GDBには、 さまざまなリアルタイム・オペレーティング・システム上で動作するプログラムをデバッグする機能が含まれています。
target vxworks machinename
VxWorksでloadコマンドを実行すると、
filenameで指定される実行ファイルがカレントなターゲット・システム上で動的にリンクされ、
シンボルがGDBに追加されます。
開発者は、
GDBを使用することによって、
ネットワークに接続されたVxWorksターゲット上のタスクを、
UNIXのホストから起動してデバッグすることができます。
VxWorksシェルから起動され、
既に実行中の状態のタスクをデバッグすることもできます。
GDBは、
UNIXホスト上で実行されるコードとVxWorksターゲット上で実行されるコードの両方を使います。
gdbプログラムは、
UNIXホスト上にインストールされて実行されます
（ホスト上のプログラムをデバッグするのに使うGDBと区別するために、
vxgdbという名前でインストールされることもあります）。
VxWorks-timeout args
vxworks-timeoutオプションをサポートするようになりました。
このオプションはユーザによってセットされるもので、
argsは、
GDBがRPCの応答を待つ秒数を表わします。
実際のVxWorksターゲットが速度の遅いソフトウェア・シミュレータであったり、
帯域の小さいネットワーク回線を介して遠距離にある場合などに使うとよいでしょう。
VxWorksとの接続に関する以下の情報は、 このマニュアルの作成時における最新の情報です。 新しくリリースされたVxWorksでは、 手順が変更されているかもしれません。
VxWorks上でGDBを使うためには、
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コマンドの引数として指定されたオブジェクト・ファイルは、
実際には2回オープンされます。
まず、
コードをダウンロードするためにVxWorksターゲットによってオープンされ、
次にシンボル・テーブルを読み込むためにGDBによってオープンされます。
2つのシステム上のカレントな作業ディレクトリが異なると、
問題が発生します。
両方のシステムが同一のファイル・システムを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です。 アタッチするときに、 タスクは実行中であってもサスペンドされていても構いません。 実行中であったタスクは、 アタッチされたときにサスペンドされます。
このセクションでは、 特定の組み込みコンフィギュレーションに固有な詳細を説明します。
target adapt dev
target amd-eb dev speed PROG
target remoteの場合と同様、
devはシリアル装置です。
speedによって回線速度を指定することができます。
PROGは、
デバッグ対象となるプログラムをPC上のDOSから見た場合の名前です。
AMD29KのEBMONプロトコル
を参照してください。
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上で実行されているこの例では、 PCポートを通信速度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による接続で、
PCのG:ドライブをUNIXホストのファイル・システムの1つとする方法です。
PC/NFS、
あるいは、
2つのシステム間を接続する類似の方法がない場合、
フロッピ・ディスクによる転送など、
UNIXシステムからPCへ29Kプログラムを転送するための他の手段を準備する必要があります。
GDBは、
シリアル回線経由で29Kプログラムをダウンロードすることはしません。
最後に、
UNIXシステム上の29Kプログラムが存在するディレクトリにcdコマンドによって移動して、
GDBを起動します。
引数には、
29Kプログラムの名前を指定します。
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にアタッチするために、
もう一度tipまたはcuを使います。
その後、
qコマンドによってEBMONをシャットダウンし、
DOSのコマンドライン・インタープリタに制御を戻します。
CTTY conと入力して、
入力されたコマンドがメインのDOSコンソールによって受け取られるようにし、
~.を入力してtipまたはcuを終了させます。
target amd-ebコマンドは、
接続に関わる問題のデバッグを支援するため、
カレントな作業ディレクトリに`eb.log'というファイルを作成します。
`eb.log'は、
EBMONに送信されたコマンドのエコーを含む、
EBMONからのすべての出力を記録します。
別のウィンドウ内でこのファイルに対して`tail -f'を実行すると、
EBMONに関わる問題やPC側での予期せぬイベントを理解する助けになることがよくあります。
target rdi dev
target rdp dev
target hms dev
deviceとspeedによって、
使用されるシリアル回線と通信速度を制御します。
target e7000 dev
target sh3 dev
target sh3e dev
日立のSH、
H8/300、
H8/500ボード
に対するリモート・デバッグを選択すると、
loadコマンドはユーザ・プログラムを日立ボードにダウンロードし、
（fileコマンドと同様）
ユーザのホスト・マシン上のGDBのカレントな実行ファイル・ターゲットとしてオープンします。
日立のSH、 H8/300、 H8/500と通信するためには、 GDBは以下の情報を知っている必要があります。
シリアル装置を明示的に指定する必要があれば、
そのための専用コマンドである、
GDBの`device port'コマンドを使用します。
portのデフォルトは、
ホスト上で最初に利用可能なポートです。
これはUNIXホスト上でのみ必要であり、
そこでは典型的には`/dev/ttya'のような名前になります。
GDBには、
通信速度を設定するためのもう1つの専用コマンド`speed bps'があります。
このコマンドもまた
UNIXホストからのみ使用されるものです。
DOSホストでは通常どおり、
GDBからではなくDOSのmodeコマンドによって回線速度を設定します
（例えば、
9600bpsの接続を確立するには
mode com2:9600,n,8,1,p
のように実行します）。
`device'コマンドと`speed'コマンドは、
日立マイクロプロセッサ・プログラムのデバッグにUNIXホストを使う場合のみ利用可能です。
DOSホストを使う場合、
GDBは、
PCのシリアル・ポート経由で開発ボードと通信するのに、
asynctsrと呼ばれる補助的な常駐プログラムに依存します。
DOS側でシリアル・ポートの設定をする場合にも、
DOSのmodeコマンドを使わなければなりません。
以下のサンプル・セッションは、 GDBの制御のもとに、 H8/300上においてプログラムを起動するのに必要とされる方法を示したものです。 この例では、 `t.x'という名前の H8/300サンプル・プログラムを使用します。 手順自体は、 日立SHやH8/500でも同様です。
まず最初に、
開発ボードを取り付けます。
この例では、
シリアル・ポートCOM2に接続したボードを使用します。
異なるシリアル・ポートを使用するのであれば、
modeコマンドの引数の中の名前を置き換えます。
デバッガにより使用される補助的な通信プログラムである
asynctsrを呼び出すときには、
シリアル・ポート名の数字の部分だけを渡します。
例えば、
以下の例における`asyncstr 2'は、
COM2においてasyncstrを実行します。
C:\H8300\TEST> asynctsr 2 C:\H8300\TEST> mode com2:9600,n,8,1,p Resident portion of MODE loaded COM2: 9600, n, 8, 1, p
注意：PC-NFSには、
asynctsrと衝突するようなバグのあることが判明しています。 DOSホスト上でPC-NFSを実行しているのであれば、 開発ボードを制御するのにasynctsrを使用するためには、 PC-NFSを停止するか、 場合によっては、 PC-NFSが実行されないようにして ホストを起動し直す必要があるかもしれません。
シリアル通信がセットアップされて、
開発ボードが接続されれば、
GDBを起動することができます。
プログラムの名前を引数にしてgdbを呼び出します。
GDBは、
通常どおり、
`(gdb)'というプロンプトによって入力待ちになります。
デバッグ・セッションを開始するには、
2つの特別なコマンドを使用します。
日立ボードに対するクロス・デバッグを指定するには
`target hms'コマンドを使用します。
また、
ボードにプログラムをダウンロードするには
loadコマンドを使用します。
loadコマンドは、
プログラムのセクション名を表示し、
さらに、
2Kのデータをダウンロードするたびに`*'を表示します。
（GDBの持っているシンボルや実行ファイルに関するデータを
ダウンロードすることなく最新の状態にしたいのであれば、
GDBのfileコマンドや
symbol-fileコマンドを使用します。
これらのコマンドとloadコマンド自体については、
ファイルを指定するコマンド
に説明されています。）
(eg-C:\H8300\TEST) gdb t.x GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 5.0, Copyright 1992 Free Software Foundation, Inc... (gdb) target hms Connected to remote H8/300 HMS system. (gdb) load t.x .text : 0x8000 .. 0xabde *********** .data : 0xabde .. 0xad30 * .stack : 0xf000 .. 0xf014 *
この時点において、
プログラムを実行したりデバッグしたりする準備が整いました。
ここからは、
普通のGDBコマンドはすべて使用することができます。
breakコマンドによるブレイクポイントのセット、
runコマンドによるプログラムの実行開始、
printコマンドやxコマンドによるデータの表示、
ブレイクポイントにおける停止後の
continueコマンドによる実行再開が可能です。
GDBのコマンドに関して詳細を知るには、
いつでもhelpコマンドを使用することができます。
しかし、 開発ボード上では、 オペレーティング・システムの機能は利用できないということを 忘れないでください。 例えば、 プログラムがハングしても、 割り込みを送信することはできません。 もちろん、 RESETボタンを押すことはできます！
開発ボード上で以下のことを行うには、 RESETボタンを使用してください。
どちらの場合でも、 開発ボード上でのRESETは、 GDBからはプログラムの「正常終了」と見えます。
E7000インサーキット・エミュレータを使って、 日立SHまたはH8/300H用のコードを開発することができます。 `target e7000'コマンドを以下のいずれかの形式で使って、 GDBをE7000に接続します。
target e7000 port speed
target e7000 hostname
telnetを使います。
いくつかのGDBコマンドはH8/300においてのみ利用可能です。
set machine h8300
set machine h8300h
set memory mod
show memory
small、
big、
medium、
compactのいずれかです。
target mon960 dev
target nindy devicename
Nindyは、 Intel 960ターゲット・システム用のROM Monitorプログラムです。 Nindyを使ってリモートのIntel 960を制御するようGDBが構成されている場合、 いくつかの方法によってGDBに960との接続方法を教えることができます。
targetコマンドを使う方法
（ターゲットを管理するコマンド
を参照してください）
Intel 960ボードのNindyインターフェイスでは、
loadコマンドはfilenameで指定されるファイルを960側にダウンロードし、
そのシンボルをGDBに追加します。
コマンドライン・オプションを一切使わずにgdbを起動すると、
通常のGDBプロンプトが表示される前に、
使用するシリアル・ポートを指定するよう促されます。
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
このプロンプトに対して、
使いたいシリアル・ポートを示す
（`/dev/tty'の後ろの）
サフィックスを入力します。
もしそうしたいのであれば、
プロンプトに空行で答えることによって、
Nindyとの接続を確立せずに起動することもできます。
この場合、
後にNindyと接続したいときにはtargetコマンドを使います
（ターゲットを管理するコマンド参照）。
接続されたNindy-960ボードとのGDBセッションを開始するための 起動オプションを以下に示します。
-r port
tty固有の一意なサフィックス
（例：`-r a'）
のいずれによっても指定することができます。
-O
注意：`-O'を指定したにもかかわらず、 実際にはより新しいプロトコルを期待しているターゲット・システムに接続しようとした場合、 接続は失敗します。 この失敗は、 あたかも通信速度の不一致が原因であるかのように見えてしまいます。 GDBは、 異なる回線速度によって再接続を繰り返し試みます。 割り込みによって、 この処理を中断させることができます。
-brk
BREAK信号を送信するよう、
GDBに対して指定します。
注意：多くのターゲット・システムは、 このオプションが必要とするハードウェアを備えていません。 このオプションが機能するボードは少数です。
標準の`-b'オプションが、 シリアル・ポート上で使用される回線速度を制御します。
reset
target m32r dev
Motorola m68k用のコンフィギュレーションにはColdFireサポート、
および、
以下のROMモニタに対するtargetコマンドが含まれています。
target abug dev
target cpu32bug dev
target dbug dev
target est dev
target rom68k dev
GDBがm68*-ericsson-*によって構成されている場合、
これらの代わりに、
特別なtargetコマンドを1つだけ持つことになります。(9)
target es1800 dev
target bug dev
GDBは、
MIPSのリモート・デバッグ用のプロトコルを使って、
シリアル回線に接続されたMIPSボードと通信することができます。
これは、
GDBの構成時にconfigureに対して`--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
target r3900 dev
target array dev
GDBは、 MIPSターゲットに対して、 以下の特別なコマンドもサポートしています。
set processor args
show processor
set processorコマンドを使ってMIPSプロセッサの種類を設定します。
例えば、
set processor r3041は、
3041チップで有効なCPOレジスタを使うようGDBに対して通知します。
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コマンドで制御することができます。
デフォルトは5秒です。
同様に、
パケットに対する確認
（ACK）
を待っている状態でのタイムアウト時間を、
set retransmit-timeout secondsコマンドで制御することができます。
デフォルトは3秒です。
それぞれの値をshow timeoutとshow retransmit-timeoutで調べることができます
（どちらのコマンドも、
GDBが`--target=mips-idt-ecoff'用に構成されている場合のみ使用可能です）。
set timeoutで設定されたタイムアウト時間は、
ユーザ・プログラムが停止するのをGDBが待っている間は適用されません。
この場合には、
GDBは永遠に待ち続けます。
これは、
停止するまでにプログラムがどの程度長く実行を継続するのかを知る方法がないからです。
target dink32 dev
target ppcbug dev
target ppcbug1 dev
target sds dev
target op50n dev
target w89k dev
target hms dev
deviceとspeedによって、
使用されるシリアル回線と通信速度を制御します。
target e7000 dev
target sh3 dev
target sh3e dev
開発者は、
GDBを使うことによって、
Sparcletターゲット上で実行中のタスクをUNIXホストからデバッグできるようになります。
GDBは、
UNIXホスト上で実行されるコードとSparcletターゲット上で実行されるコードの両方を使用します。
gdbは、
UNIXホスト上にインストールされて実行されます。
remotetimeout 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)
target sparclite dev
GDBは、 Tandem STDBUGプロトコルを実行しているTandem ST2000電話交換機に対して使うことができます。
ST2000をホスト・システムに接続する方法については、 製造元のマニュアルを参照してください。 ST2000が物理的に接続されれば、 それをデバッグ環境として確立するには以下を実行します。
target st2000 dev speed
devは通常、
シリアル回線によってST2000と接続される`/dev/ttya'のようなシリアル装置の名前です。
代わりに、
hostname:portnumberという構文を使って
（例えば、端末多重化装置経由で接続されたシリアル回線への）
TCP接続としてdevを指定することもできます。
このターゲットに対して、
loadコマンドとattachコマンドは定義されていません。
通常スタンドアロンで操作している場合と同様、
ST2000にユーザ・プログラムをロードしなければなりません。
GDBは
（シンボルのような）
デバッグ用の情報を、
ホスト・コンピュータ上にある同一プログラムのデバッグ・バージョンから読みとります。
ST2000での作業を支援するために、 以下の補助的なGDBコマンドが利用可能です。
st2000 command
connect
Zilog Z8000をターゲットとしてデバッグするための コンフィギュレーションが行われると、 GDBには、 Z8000シミュレータが組み込まれます。
Z8000系については、 `target sim'によって、 Z8002 （Z8000アーキテクチャの、 セグメントを持たない変種） またはZ8001 （セグメントを持つ変種） をシミュレートします。 シミュレータは、 オブジェクト・コードを調べることで、 どちらのアーキテクチャが適切であるかを認識します。
target sim args
このターゲットを指定した後には、
ホスト・コンピュータ上のプログラムをデバッグするのと同様の方法で、
シミュレートされたCPU用のプログラムをデバッグすることができます。
新しいプログラムのイメージをロードするには
fileコマンドを使い、
ユーザ・プログラムを実行するにはrunコマンドを使う、
という具合です。
Z8000シミュレータでは、 通常のマシン・レジスタ （レジスタ参照） がすべて利用可能であるだけでなく、 特別な名前を持つレジスタとして、 3つの追加情報が提供されています。
cycles
insts
time
これらの変数は、 GDBの式の中で普通に参照することができます。 例えば、 `b fputc if $cycles>5000'は、 シミュレートされたクロック・ティックが最低5,000回発生した後に停止するような、 条件付きブレイクポイントを設定します。
このセクションでは、 ネイティブ・デバッグ、 クロス・デバッグのいずれにおいてもGDBの使用に対して影響を及ぼすような、 アーキテクチャ上の特徴について説明します。
set rstack_high_address address
set rstack_high_addressコマンドによってレジスタ・スタックの最終アドレスを指定することによって、
この問題を回避することができます。
引数はアドレスでなければなりません。
`0x'を先頭に記述することで、
アドレスを16進数で指定することができます。
show rstack_high_address
次のセクションを参照してください。
AlphaベースのコンピュータとMIPSベースのコンピュータは、 変わったスタック・フレームを使用しています。 そのため、 関数の先頭を見つけるために、 GDBはときどきオブジェクト・コードを逆方向に検索する必要があります。
応答時間を改善するために （特に、 このような検索を実行するのに、 速度の遅いシリアル回線を使用するほかない、 組み込みアプリケーションの場合）、 以下に列挙するコマンドを使用して検索量を制限するとよいでしょう。
set heuristic-fence-post limit
heuristic-fence-postによる検索バイト数も多くなり、
したがって検索の実行により長い時間がかかります。
show heuristic-fence-post
これらのコマンドは、 GDBが、 Alphaプロセッサ上、 または、 MIPSプロセッサ上においてプログラムをデバッグするよう構成されている場合に のみ使用することができます。