JPH02184935A - デバッガの入出力支援方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［概要］ 本発明は入出力のハードウェアが、本体側プロセッサと
は独立に動作する【１０プロセツサ側で制御されるよう
に構成されたシステムにおいて、本体側のカーネルやド
ライバ等のプログラムをデバッグする際のＩ１０支援の
方法に関し、カーネル用デバッガの入出力をＩＯＰ側に
接続された入出力装置でサポートすることができるよう
にすることを目的とし、 １０Ｐ側のファームウェアをまず停止させる割り込みを
行ない割り込みのための優先処理を行なわせてＩＯＰ上
で動作するプログラムを切り換え、その後再びＩＯＰ側
にファームウェア再開要求の割り込み要求を与えて先に
セーブしたＩＯＰの状態をリストアし、これに基づきフ
ァームウェアを再開させ、カーネル用デバッガの入出力
としてＩＯＰ側に接続されたディスプレイ装置あるいは
キーボード装置を直接使用できるように構成する。

［産業上の利用分野］ 本発明は、人出力（以下Ｉ１０と略す）のハードウェア
が、本体側のシステムプロセッサの管理下にあり本体側
プロセッサとは独立に動作するＩ１０プロセッサ側で制
御されるように構成されたシステムにおいて、本体側の
カーネル（オペレーティングシステムの中核をなす部分
）やドライバ等のプログラムをデバッグする際のＩ１０
支援の方法に関する。

［従来の技術］ 従来よりディスプレイ画面表示、キーボード入力等を本
体側のプロセッサとは独立したＩ１０プロセッサで制御
するグラフィック表示機構を持ったシステムはよく知ら
れている。

近年のオフィスオートメーション（ＯＡ）やエンジニア
リングワークステーション等においては、高度なマンマ
シンインタフェースを実現するようになったため、ウィ
ンドウ表示等にみられるようにグラフィック処理にかか
るプロセッサの負荷がますます増大するという傾向にあ
る。このグラフィック処理にかかるプロセッサの負荷を
減らすために、グラフィック処理を本体側のプロセッサ
（以下ＳＰと略す）とは独立した専用のＩ１０プロセッ
サ（以下１０Ｐと略す）で行なうようにしたシステムが
開発されている。また、このようなシステムにおいては
、マウスやキーボード入力等のエコーバック処理をリア
ルタイムで行なう必要性から、それらの入力装置もグラ
フィック側のＩＯＰて処理させる傾向にある。

しかしながら、上記の構成には次のような問題がある。

■ディスプレイ描画機能は専用のＩＯＰ側にあるため、
一般にＳＰから直接表示用のフレームメモリを自由にア
クセスすることができない。したがって、ＳＰが自由に
フレームメモリにアクセスできることを前提に作成され
たアプリケーションプログラムの移植はきわめて困難で
ある。

■ＳＰとＩＯＰとの間でのコマンドやデータの受渡しに
かかる負荷がシステム性能に大きく影響する。すなわち
、グラフィック部の描画性能が高くなればなるほど、シ
ステムとしての性能はＳＰと１０Ｐとの通信処理にかか
る時間で決ってしまう。

そのため、本体側のＳＰがグラフィック側のｌＯＰに処
理を依頼する描画コマンドの処理単位としては、１本の
線描画というような原始的なものではなく、ウィンドウ
の再描画等のように一連の処理単位をひとまとめにした
処理単位にする必要がある。

上記■の問題点については、近年グラフィック処理にお
ける描画データそのものを個々の装置依存型のものから
固有のハードウェアに依存しないで利用できるようなも
のにするために、図形インタフェースの標準化を進める
必要性が、高まっている。特に、ＩＳＯのＣＧＩ　　（
ＣｏｍｐｕｔｅｒＧｒａｐｈｉｃ　　Ｉｎｔｅｒｆａｃ
ｅ）などは今後の図形標準インタフェースとして重要視
されており、ＣＧＩ準拠のグラフィックコントローラの
開発も盛んである。したがって、ＩＯＰによるグラフィ
ック描画機能がＣＧＩのような規格化された標準図形イ
ンタフェースの仕様を完全に満たすものであれば標準図
形インタフェースに従ったアブリケーションの移植は問
題ないはずである。

これはパーソナルコンピュータについても言える。パー
ソナルコンピュータの次期Ｏ８（０１）ｅｒａｔｉｎｇ
　　Ｓｙｓｔｅｍ）として注目されているＯ８／２でサ
ポート予定のプレゼンテーションマネジャーではアプリ
ケーションプログラムに対して標準的なグラフィックイ
ンタフェースを提供しており、アプリケーションプログ
ラムが独自にハードウェア資源を直接アクセスして図形
描画等を行なうことは許してはいない。したがって、プ
レゼンテーションマネジャーの提供する図形描画等の機
能を、本体のＳＰで処理するのではなく、独自にグラフ
ィック描画用のＩＯＰを設けてそちらで処理するように
しても、アプリケーションの動作は保証されるというこ
とである。それ故、上記■の点は、現在はかなり問題で
あるけれども将来的にはそれほど大きな問題とならない
とも言える。

他方上記■の問題については、上述したようにＳＰがグ
ラフィック用のＩＯＰに対してどのような処理単位で処
理を依頼するかということが重要である。上記■の問題
で述べた標準図形インタフェースは本体側のアプリケー
ションプログラムからみた上での話であるので、ＳＰと
ＩＯＰの間でのインタフェースでは通信によるオーバヘ
ッドを最小とするようなインタフェースとするべきであ
り、この問題に対する回答は個々のシステムに依存する
と言える。

さて、上述したようなグラフィック描画機能、マウス、
キーボード等の入力１能を専用のＩＯＰで実現するシス
テムにおいては、一般に本体側のＳＰからはディスプレ
イ表示、キーボード入力等のハードウェアを直接制御す
ることができないため、本体側プログラムのデバッグ環
境では以下のような問題が発生する。

すなわち、本体側のＯ８部のカーネルやドライバ（ＩＯ
Ｐとのインタフェース部も含む）等のデバッグを行なう
際にはカーネル用のデバッガを使用する必要があるが、
このカーネル用のデバッガの入出力の手段としてシステ
ムに接続されたディスプレイ装置やキーボード装置を使
用することができないという問題である。

ここで、カーネル用のデバッガについて説明する。ＵＮ
ＩＸ　（ＡＴ＆Ｔのベル研究所が開発したＯ８で、ＵＮ
ＩＸは登録商標）等に代表されるＯ８は、一般にプロセ
スの取り得る状態としてカーネルモードとユーザモード
という２つのモードを持っている。カーネルモードとは
、Ｏ８のカーネルやドライバ等が動作するときに取り得
るモードで、ハードウェアの資源を直接制御できるモー
ドである。一方、ユーザモードとは、Ｏ８の提供するサ
ービスを利用してアプリケーションプログラムが動作す
るときに取り得るモードであり、一般にハードウェアの
資源に直接アクセスすることはできない。すなわち、ユ
ーザモードのプロセスが実行されるということは、Ｏ８
による各種のサービスの動作が保証されているというこ
とである。

カーネル用のデバッガに対してユーザ用のデバッガとい
うのもあるが、これはユーザモードで動作するアプリケ
ーションプログラムをデバッグするためのデバッガであ
り、カーネルやドライバ等の動作は保証されていること
が前提となっている。

したがって、ユーザ用のデバッガではデバッガ自体の入
出力にＳＰとＩＯＰ間のインタフェースによってシステ
ム側で提供された通常の入出力サ−ビスを利用すること
が可能である。

これに対してカーネル用のデバッガでは、カーネルやド
ライバをデバッグするのが目的であるため、自身の入出
力の機能にカーネルやドライバを使用するわけにはいか
ない。そのため、通常はＴＴＹ　（ｔｅｌｅｔｙｐｅｗ
ｒｌ　ｔｅｒ）端末等を接続し、これを入出力に利用す
る方法が採られる。

しかしながら、カーネル用のデバッガを利用するとき必
ずＴＴＹ端末を必要としたのでは、システム開発上でも
、またＯ８やドライバの障害発生時の調査等においても
大変不都合である。

そのため、従来ディスプレイ表示やキーボード入力のハ
ードウェアがＳＰ側にあるシステムでは、カーネル用の
デバッガがＯ８やドライバとは別の手段で直接ハードウ
ェアを制御することにより、システムに接続されたディ
スプレイ装置やキーボード装置を自身の入出力の手段と
していた（第５図）。第５図において、１１はターゲッ
トプログラムブロック、１３はカーネル用のデバッガ、
３０はこれらターゲットプログラムブロック１１及びカ
ーネル用のデバッガ１３を受ける入出力ハードウェアで
ある。４１は該入出力ハードウェア３０と接続されるデ
ィスプレイ装置、４２は同じく入出力ハードウェア３０
と接続されるキーボード装置である。

しかし、入出力のハードウェア３０がＩＯ２側にある第
６図に示すようなシステムでは、カーネル用のデバッガ
はハードウェアを直接制御することができないため、入
出力をＴＴＹ端末等に頼る他なかった。同図において、
１０はＳＰ側、２０はＩＯ２側であり、入出力ハードウ
ェア３０はＩＯ２側に設けられている。１２はＳＰ側に
設けられた通信用メモリ領域でありＩＯ２側のファーム
ウェアブロック２２と接続されている。２１はＳＰ側の
ターゲットプログラムブロック１１及びＩｏＰ側のファ
ームウェアブロック２２とを接続するセマフォレジスタ
である。

［発明が解決しようとする課題］ 要するに、ＳＰ側にあるカーネル用のデバッガ１３がＩ
Ｏ２側に接続されたディスプレイ装置やキーボード装置
４２を利用してデバッガ自身の入出力を行なうためには
以下の問題点が解決されなくてはならない。

■まず、デバッガ使用時でのデバッガによるシステム側
の制御を説明する。

メモリダンプコマンド等のデバッガコマンド入力時にお
いては、ＳＰ側の制御はデバッガプログラムにあり、デ
バッグ対象プログラムであるカーネルやドライバは動作
していない（すなわち、デバッグプログラムが動作して
いる）。このときデバッガは自身のワーク領域内にデバ
ッグ対象プログラムを動作させるときに必要な情報（Ｃ
ＰＵ内の各種レジスタの値）を保存している。そして、
プログラム実行コマンド（ｇコマンド）が入力されるこ
とにより、ＣＰＵにワーク領域内に保存していたＣＰＵ
レジスタの値を設定し、制御をターゲットプログラムに
渡す。ターゲットプログラムはこれにより動作するが、
デバッガでブレークポイントが設定されていた場合には
その命令を解読したとき、あるいはトレースモードにあ
った場合には１命令実行後に、例外が発生し、再びデバ
ッガに制御が戻る。すなわち、ＳＰ側ではターゲットプ
ログラムが動作している場合とデバッガプログラム自体
が動作している場合とがある。

以上のことから、ＳＰ側でターゲットプログラム１１が
動作しているときは、ＩＯ２側のファームウェア２２は
ＳＰ側のドライバと通信を行い、本来の入出力処理を行
なう必要があるが、ＳＰ側でデバッガプログラム１３が
動作している゛ときは、なんらかの手段でＳＰ側のカー
ネル用のデバッガ１３とデータの受渡し処理が行えなく
てはならない。また、再度ＳＰ側の制御がターゲットプ
ログラム１１に移った時はＩＯ２側のファームウェア２
２は以前まで実行していた処理の続きを実行てきなくて
はならない。すなわち、ＳＰ側でのデバッガの起動、タ
ーゲットプログラムの起動に同期してＩＯ２側のファー
ムウェア２２は処理の停止、再開を行ない、ファームウ
ェア停止時にＳＰ側のデバッガのための人出力のサポー
トが行えなくてはならない。なお、ここでのファームウ
ェアとは、システムのパワーオン時にＩＯ２側のメモリ
上にダウンロードされて起動されるＩＯ２側の制御プロ
グラムをいう。

■上記■でＩＯ２側のファームウェア２２が停止状態に
あるときに、ＩＯ２側ではＳＰ側で動作しているデバッ
ガ１３のためにディスプレイ表示やキーボード入力のた
めのサービスをサポートする必要がある。また、このサ
ービスで用いるＳＰ側とＩＯ２側との間の通信手段は、
ＳＰ側のターゲットプログラム１１とＩＯ２側のファー
ムウェア２２が用いているものと同じものであってはな
らない。なぜならば、かりに同様の手段で通信を行なっ
た場合は、ＳＰ側でデバッガが起動されることによって
ターゲットプログラム１１がＩＯＰ側のファームウェア
２１と通信していた領域のデータを破壊してしまうから
である。

本発明の目的は、このような課題に鑑み、入出力のハー
ドウェアがＩＯＰ側でしかアクセスできないシステムで
、ＳＰ側のカーネル用デバッガの入出力をＩＯＰ側に接
続された入出力装置でサポートすることができるデバッ
ガの入出力支援方法を提供することにある。

［課題を解決するための手段］ 第１図は本発明の方法を示す原理フローである。

本発明は次のステップによりデバッガの入出力を支援す
る。

本体側のプロセッサ側でカーネル用デバッガが起動され
ると入出力プロセッサ側にファームウェア停止要求のハ
ードウェア割り込みを発生しくステップ■）、 入出力プロセッサ側ではその割り込み要因を落し、割り
込み発生時の入出力プロセッサ側の状態を特定領域にセ
ーブした後優先制御の処理を行ない、その後通常のファ
ームウェアによるハードウェア操作とは別に独自にハー
ドウェアを制御することのできる入出力プロセッサ側の
ＲＯＭ部において必要な初期化その他を行ない（ステッ
プ（２））、カーネル用のデバッガが入出力プロセッサ
側のＲＯＭプログラムと通信することでデバッガの入出
力の手段を提供しくステップ（３））、カーネル用デバ
ッガにより夕゛−ゲットプログラムの起動時に入出力が
ディスプレイかキーボードであった場合には、本山カプ
ロセッサ側にファームウェア再開要求のハードウェア割
り込みを発生すると共にターゲットプログラムに制御を
移しくステップ■）、 入出力プロセッサ側は前記ファームウェア再開要求のハ
ードウェア割り込みを受けるとその割り込み要因を落と
すと共に、前記ファームウェアの停止時にセーブしてい
た入出力プロセッサ側の状態を特定領域からリストアし
、これを基にファームウェアを再開させる（ステップ■
）。

［作用］ 本発明では、ＳＰ側からＩＯＰ側のファームウェアをま
ず停止させる割り込みを行なって割り込みのための優先
処理を行なわせてＩＯＰ上で動作するプログラムを切り
換え、その後再びＳＰ側からＩＯＰ側にファームウェア
再開要求の割り込み要求を与えて先のファームウェア停
止時にセーブしていたＩＯＰの状態をリストアし、これ
に基づきファームウェアを再開させる。これにより、カ
ーネル用デバッガは、入出力として、ＩＯＰ側に接続さ
れたディスプレイ装置あるいはキーボード装置を直接使
用できる。

［実施例］ 第２図は本発明の方法を実施するための装置の一実施例
構成図である。図において、１０はＳＰ側、２０はＩＯ
Ｐ側、３０は入出力ハードウェア、４１はディスプレイ
装置、４２はキーボード装置である。

ＳＰ側１０において、１１はカーネルやドライバ等から
なるターゲットプログラムを実行するターゲットプログ
ラムブロックで、セマフォレジスタ２１と通信用メモリ
１２を互いにアクセスすることによりＩＯＰ側とデータ
の受渡しを行なうことができる。１３はカーネルやドラ
イバ等のデバッグを行なう機能を有するカーネル用のデ
バッガである。

１０Ｐ側２０において、２２はＩＯＰ側にターゲットプ
ログラムブロック１１とデータの受渡しを行い、ディス
プレイ装置４１での表示およびキーボード装置４２によ
る入力等の処理を行なう機能、すなわち通常のファーム
ウェアによるハードウェア操作を行なう機能を有するフ
ァームウェアブロック、２３はＲＯＭ部で、前記通常の
ファームウェアによるハードウェア操作とは別に独自に
ハードウェアを制御することのできるプログラムが格納
されており、ＩＯＰ側のパワーオン時にＩＯＰ側の初期
化やＩＯＰハードウェアの診断を実行し、その後１０Ｐ
フアームウエアをＳＰ側からダウンロードしＩＯＰ側フ
ァームウェアブロック２２に制御権を移す機能を有する
。

２４は実行制御レジスタで、ＳＰ側からＩＯＰ側に対し
てＮＭＩ　（ｎｏｎ−ｍａｓｋａｂ　１ｅｉｎｔｅｒｒ
ｕｐｔ）割り込みを要求したり、ＲＯＭ部２３がＳＰ側
からコマンドを受は付ける状態になったときにＳＰ側か
らのコマンド実行要求を受は付けるレジスタである。

実行制御レジスタ２４は例えば第３図に示すようなフォ
ーマットとなっている。すなわち、８ビツトの中、下位
４ビツトはＤＯＰＣ（Ｄｅｖ　ｉ　ｃｅ　　０ｐｅｒａ
ｔ　ｉｏｎ　　Ｃｏｄｅ）で、ＩＯＰ側の動作指定に利
用するコマンドコード設定領域である。また、５ビツト
目のＡＲにはｌ０ＰｆｆｌｌｌこＮＭＩ割り込みを発生
させるビットコマンドがセットされ、最上位ビットのＥ
ＸはＩＯＰ側に対してコマンドの実行を要求する信号が
セットされる。

２５はカーネル用のデバッガ１３に与える１０Ｐ側のス
テータスを保持するＩＯＰステータスレジスタ、２６は
カーネル用のデバッガ１３とＲＯＭ部２３との間で授受
するデータを保持するデータ通信用レジスタで、ＳＰ側
とＩＯＰ側とでり−ド／ライトが可能になっている。

このような構成における動作を次に説明する。

通常、システムが動作しているときには、ＳＰ側のドラ
イバとＩＯＰ側のファームウェアはセマフォレジスタ２
１でセマフォ同期をとりながらＳＰ側のメモリ領域１２
を互いにアクセスしてコマンド、データの授受を行なっ
ている。

ここで、ＳＰ側のカーネル用のデバッガ１３が起動され
た場合（起動の要因はコマンド入力によるもの、ターゲ
ットプログラム中に設定されたブレイクポイントをＳＰ
側がフェッチし解読したために例外処理から呼ばれるも
の、あるいはトレースモードが設定されていたために例
外処理から呼ばれるもの等、多くの場合がある）につい
て、第４図（ａ）および第４図（ｂ）を参照して説明す
る。

カーネル用のデバッガ１３は自身に制御が移ると、まず
自身の入出力装置としてＴＴＹ端末を使用するモードに
なっているかあるいはＩＯＰ側のディスプレイ装置４１
やキーボード装置４２を使用するモードになっているか
を調べる。後者の場合には以下のシーケンスに従った処
理が実行される。

■カーネル用のデバッガ１３は実行制御レジスタ２４の
コマンドコード設定領域にファームウェア停止要求コー
ドを設定し、かつＩＯＰへの割り込み（ＮＭＩ割り込み
）指定ビット（ＡＲビット）を立て（ＯＮとし）、ＩＯ
Ｐ側に対してＮＭＩ割り込みを発する。その後は実行制
御レジスタ２４のＤＯＰＣコードがクリアされるのをポ
ーリングチエツクする。

■ＩＯＰ側では、ＮＭＩ割り込みの例外処理部に制御が
移る。この例外処理部では実行制御レジスタ２４の内容
をリードし、ＳＰ側からのＮＭＩ割り込み要求であるか
を調べ、そうである場合にはＤＯＰＣに設定されたコー
ドを調べる。ここでは、ファームウェア停止要求コード
が設定されているので、ＡＲビットをクリアしてＮＭＩ
割り込みの要因を落とした後ＮＭＩ割り込みが入ったと
きのＩＯＰ内部レジスタの値（プログラムカウンタ、ス
タックポインタ等のファームウェアの再起動の際に必要
なものすべての値）を特定領域に設定する。

その後ファームウェアで必要であるならば、ファームウ
ェア内での優先制御の処理を行なった後ＲＯＭ部２３に
ジャンプしてＲＯＭ部に制御を移す。

■ＲＯＭ部２３では、スタックポインタの設定等の必要
な初期化を行なった後、実行制御レジスタ２４のＤＯＰ
ＣをクリアしＳＰ側のカーネル用のデバッガ１３の入出
力用のコマンドの受付可能状態に入る。すなわち、ＩＯ
Ｐステータスレジスタ２５にあるＩＯＰ　　Ｂｕｓｙビ
ットをクリアし、実行制御レジスタ２４のＥＸビットの
ポーリング状態に入る。

■ＳＰ側では、ＩＯＰによってＤＯＰＣがクリアされる
のでＤＯＰＣコードのポーリング状態から抜けてＲＯＭ
部と入出力データの受渡しを行なう。

すなわち、ＩＯＰステータスレジスタ２５のＢｕｓｙビ
ットをチエツクし、ＩＯＰ側がＢｕｓｙでなければ実行
制御レジスタ２４のＤＯＰＣに入出力用のコマンドコー
ドを設定し、ＥＸビットをＯＮとすることでＲＯＭ部に
ディスプレイ装置４１への表示およびキーボード装置４
２からの文字入力の処理を依頼する。ＳＰ側とＩＯＰ側
との間のデータ受渡しはデータ通信レジスタ２６によっ
て行なわれる。

以上の処理により、ＩＯＰ側フ側御アームウェア止とＲ
ＯＭ部によるＳＰ側のカーネル用デバッガのための入出
力のサポートが可能となる。

次にＳＰ側での制御がデバッガからターゲットプログラ
ムブロックに移るときの動作について説明する。

■カーネル用のデバッガ１３はターゲットプログラムの
起動指示等のコマンド入力によりターゲットプログラム
ブロック１１に制御を移すが、その際に自身が入出力の
ためにＴＴＹ端末を使用しているか、あるいはＩＯＰ側
のディスプレイ装置４１またはキーボード装置４２を使
用しているかをチエツクする。後者の場合には、実行制
御レジスタ２４のコマンドコード設定領域（ＤＯＰＣ）
にファームウェアの再開要求コードを設定し、かつ１０
Ｐへの割り込み（８Ｍ１割り込み）指定ビット（ＡＲビ
ット）をＯＮにすることによって１０Ｐ側にＮＭ１割り
込みを与え、その後ターゲットプログラムブロック１１
に制御を移す。

■ＩＯＰ側では、８Ｍ１割り込みの例外処理部に制御が
移る。この例外処理部では、実行制御レジスタ２４の内
容を読み出し、ＳＰ側からの８Ｍ１割り込み要求かどう
かを調べ、そうである場合にはＤＯＰＣに設定されたコ
ードを調べる。ここではファームウェア再開要求コード
が設定されているので、ＡＲビットをクリアして８Ｍ１
割り込みの要因を落し、その後特定領域に保存されてい
る１０Ｐ内部レジスタの値を基にしてファームウェアを
再開させる。

なお、実施例ではカーネル用のデバッガの入出力サポー
トをＲＯＭ部で行なっている構成としたが、これに限定
するものではない。例えば、カーネル用のデバッガを使
用するのがＩＯＰ側にファームウェアの存在する場合の
みでよければ、ＩＯＰ側のファームウェアにカーネル用
のデバッガのための入出力サポートルーチンがあっても
かまわない。

また、ＳＰとＩＯＰ間の通信レジスタ（実行制御レジス
タ２４．ＩＯＰステータスレジスタ２５゜データ通信用
レジスタ２６）が上記と同様の作用をするものであれば
、上記構成と全く同じである必要はない。例えば、上記
説明ではＩＯＰ側への割り込み要求時にファームウェア
の停止要求や再開要求のコードを実行制御レジスタのＤ
ＯＰＣで通知しているが、これをデータ通信用レジスタ
２６で行なっても同様の効果が得られる。

［発明の効果］ 以上説明したように、本発明によれば、グラフィック描
画機能やキーボード等の入力機能を専用のＩＯＰで実現
しているシステムにおいても、ＳＰ側からディスプレイ
装置やキーボード装置等のハードウェアを直接制御して
カーネルやドライバ等のデバッグを行なうことができる
。

【図面の簡単な説明】

第１図は本発明の方法を示す原理フロー第２図は本発明
の方法を実施するための装置の一実施例構成図、 第３図は実行制御レジスタのデータフォーマット、 第４図（ａ）および第４図（ｂ）は第２図に示す装置の
動作フローを示す図、 第５図および第６図は従来のシステムの概念的構成図で
ある。 １０はＳＰ側、 １１はターゲットプログラムブロック、１２は通信用メ
モリ、 １３はカーネル用のデバッガ、 ２０はＩＯＰ側、 ２１はセマフォレジスタ、 ２２はファームウェアブロック、 ２３はＲＯＭ部、 ２４は実行制御レジスタ、 ２５はＩＯＰステータスレジスタ、 ２６はデータ通信用レジスタ、 ３０は入出力ハードウェア、 ４１はディスプレイ装置、 ４２はキーボード装置である。

Claims (1)

1. 【特許請求の範囲】 ディスプレイ画面表示、キーボード入力等を本体側のプ
   ロセッサとは独立した入出力プロセッサで制御するグラ
   フィック表示機能を持ったシステムにおいて、 本体側のプロセッサ側でカーネル用デバッガが起動され
   ると入出力プロセッサ側にファームウェア停止要求のハ
   ードウェア割り込みを発生し（ステップ（１））、 入出力プロセッサ側ではその割り込み要因を落し、割り
   込み発生時の入出力プロセッサ側の状態を特定領域にセ
   ーブした後優先制御の処理を行ない、その後通常のファ
   ームウェアによるハードウェア操作とは別に独自にハー
   ドウェアを制御することのできる入出力プロセッサ側の
   ＲＯＭ部において必要な初期化その他を行ない（ステッ
   プ（２））、カーネル用のデバッガが入出力プロセッサ
   側のＲＯＭプログラムと通信することでデバッガの入出
   力の手段を提供し（ステップ（３））、 カーネル用デバッガによりターゲットプログラムの起動
   時に入出力がディスプレイかキーボードであった場合に
   は、入出力プロセッサ側にファームウェア再開要求のハ
   ードウェア割り込みを発生すると共にターゲットプログ
   ラムに制御を移し（ステップ（４））、 入出力プロセッサ側は前記ファームウェア再開要求のハ
   ードウェア割り込みを受けるとその割り込み要因を落と
   すと共に、前記ファームウェアの停止時にセーブしてい
   た入出力プロセッサ側の状態を特定領域からリストアし
   、これを基にファームウェアを再開させ（ステップ（５
   ））、 本体側のプロセッサ側のカーネルやドライバ等のプログ
   ラムをデバッグする際の入出力を支援するようにしたこ
   とを特徴とするデバッガの入出力支援方法。