(57)【特許請求の範囲】
【請求項１】
複数の実行ユニットが連携して動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグシステムであって、
前記複数の実行ユニット毎に設けられ、デバッグ用プログラムの起動を指示するデバッグ用プログラム起動指示を受信すると、当該デバッグ用プログラム起動指示により指定されている実行ユニットに対して受信した前記デバッグ用プログラム起動指示を振り分ける起動指示振り分け手段と、
前記複数の実行ユニット毎に設けられ、前記起動指示振り分け手段により振り分けられたデバッグ用プログラム起動指示に基づいて、指定された実行ユニット上にデバッグ用プログラムを起動する複数のデバッグ用プログラム起動手段とを備え、
前記各実行ユニット上において、割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラによって他の実行ユニットからの割り込みが発生した際に、通常動作プログラムにより実行されたプロセスであって暴走している前記プロセスを停止させるプロセス制御手段と、前記プロセス制御手段によるプロセス制御が行われた後、得られたレジスタ、キャッシュメモリ、フラッシュメモリを含む予め設定されたメモリ内の情報を、前記割り込みを発生させた前記他の実行ユニットに対して送信する応答生成手段とが実現され、
前記各実行ユニットのいずれかにおいて起動されるデバッグ用プログラムによって、デバッグ対象の実行ユニットに対して割り込みを発生させる実行ユニット間割り込み生成手段と、デバッグ対象の前記実行ユニットにおける応答生成手段からの応答を受信する応答受信手段とが実現されたデバッグシステム。
【請求項２】
前記プロセス制御手段は、オペレーティングシステム内に備えられたプロセス制御変更手段に対して、外部からの指示に基づいてプロセス変更指示を行うことにより前記暴走している前記プロセスを停止させる、請求項１記載のデバッグシステム。
【請求項３】
前記プロセス制御手段は、前記の割り込みが発生した場合に、オペレーティングシステム内に備えられたＡＰＩ（Application Program Interface）、システムコールを含む所定の処理手順により、制御対象プロセスに対してプロセス制御シグナルを発行することにより前記暴走している前記プロセスを停止させる、請求項１記載のデバッグシステム。
【請求項４】
前記プロセス制御手段は、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスを別のアドレスに変更して、不正アドレス参照例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項１記載のデバッグシステム。
【請求項５】
前記プロセス制御手段は、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスに存在する命令を、別の命令に変更して、例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項１記載のデバッグシステム。
【請求項６】
複数の実行ユニットが連携して動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグ方法であって、
前記複数の実行ユニット毎に設けられた起動指示振り分け手段により、デバッグ用プログラムの起動を指示するデバッグ用プログラム起動指示を受信すると、当該デバッグ用プログラム起動指示により指定されている実行ユニットに対して受信した前記デバッグ用プログラム起動指示を振り分けるステップと、
前記複数の実行ユニット毎に設けられたデバッグ用プログラム起動手段により、振り分けられた前記デバッグ用プログラム起動指示に基づいてデバッグ対象実行ユニット上にデバッグ用プログラムを起動するステップと、
前記各実行ユニット上において、割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラによって実現されたプロセス制御手段により、他の実行ユニットからの割り込みが発生した際に、通常動作プログラムにより実行されたプロセスであって暴走している前記プロセスを停止させるステップと、
前記プロセス制御手段によるプロセス制御が行われた後、得られたレジスタ、キャッシュメモリ、フラッシュメモリを含む予め設定されたメモリ内の情報を、前記割り込みハンドラによって実現された応答生成手段が、前記割り込みを発生させた前記他の実行ユニットに対して送信するステップと、
デバッグ対象の前記実行ユニットからの応答を、デバッグ用プログラムによって実現された応答受信手段が受信するステップと、を備えたデバッグ方法。
【請求項７】
前記プロセス制御を行うステップでは、オペレーティングシステム内に備えられたプロセス制御変更手段に対して、外部からの指示に基づいてプロセス変更指示を行うことにより前記暴走している前記プロセスを停止させる請求項６記載のデバッグ方法。
【請求項８】
前記プロセス制御を行うステップでは、前記割り込みが発生した場合に、オペレーティングシステム内に備えられたＡＰＩ（Application Program Interface）、システムコールを含む所定の処理手順により、制御対象プロセスに対してプロセス制御シグナルを発行することにより前記暴走している前記プロセスを停止させる、請求項６記載のデバッグ方法。
【請求項９】
前記プロセス制御を行うステップでは、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスを別のアドレスに変更して、不正アドレス参照例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項６記載のデバッグ方法。
【請求項１０】
前記プロセス制御を行うステップでは、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスに存在する命令を、別の命令に変更して、例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項６記載のデバッグ方法。
【請求項１１】
複数の実行ユニットが連携して動作するデバッグシステムにおいて実行されるプログラムのデバッグを行うためのデバッグ方法を前記実行ユニットに実行させるためのプログラムであって、
前記複数の実行ユニット毎に設けられた起動指示振り分け手段により、デバッグ用プログラムの起動を指示するデバッグ用プログラム起動指示を受信すると、当該デバッグ用プログラム起動指示により指定されている実行ユニットに対して受信した前記デバッグ用プログラム起動指示を振り分ける処理と、
前記複数の実行ユニット毎に設けられたデバッグ用プログラム起動手段により、振り分けられた前記デバッグ用プログラム起動指示に基づいてデバッグ対象実行ユニット上にデバッグ用プログラムを起動する処理と、
前記各実行ユニットのいずれかにおいて起動されるデバッグ用プログラムによって実現された実行ユニット間割り込み生成手段により、デバッグ対象の実行ユニットに対して割り込みを発生させる処理と、
前記各実行ユニット上において、割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラによって実現されたプロセス制御手段により、他の実行ユニットからの割り込みが発生した際に、通常動作プログラムにより実行されたプロセスであって暴走している前記プロセスを停止させる処理と、
前記割り込みハンドらによって実現された応答生成手段により、前記プロセス制御手段によるプロセス制御が行われた後、得られたレジスタ、キャッシュメモリ、フラッシュメモリを含む予め設定されたメモリ内の情報を、割り込みを発生させた実行ユニットに対して送信する処理、前記応答生成手段により、デバッグ対象の前記実行ユニットからの応答を、デバッグ用プログラムが起動された実行ユニットが受信する処理と、
を前記実行ユニットに実行させるためのプログラム。
【請求項１２】
前記プロセス制御を行う処理では、オペレーティングシステム内に備えられたプロセス制御変更手段に対して、外部からの指示に基づいてプロセス変更指示を行うことにより前記暴走している前記プロセスを停止させる、請求項１１記載のプログラム。
【請求項１３】
前記プロセス制御を行う処理では、前記割り込みが発生した場合に、オペレーティングシステム内に備えられたＡＰＩ（Application Program Interface）、システムコールを含む所定の処理手順により、制御対象プロセスに対してプロセス制御シグナルを発行することにより前記暴走している前記プロセスを停止させる、請求項１１記載のプログラム。
【請求項１４】
前記プロセス制御を行う処理では、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスを別のアドレスに変更して、不正アドレス参照例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項１１記載のプログラム。
【請求項１５】
前記プロセス制御を行う処理では、前記割り込みが発生した場合に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスに存在する命令を、別の命令に変更して、例外を発生させることにより前記暴走している前記プロセスを停止させる、請求項１１記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデバッグシステム、デバッグ方法およびデバッグプログラムに関し、特に複数の実行ユニットを有するシステムにおけるデバッグシステム、デバッグ方法およびデバッグプログラムに関する。
【背景技術】
【０００２】
近年、開発するプログラムの規模は年々増大してきており、デバッグ作業に要する時間が製品開発スケジュールに与える影響が大きくなってきている。このため、効率よくデバッグできる環境の構築が望まれている。効率よくデバッグするための手法として、特許文献１の「プロセッサ情報収集装置およびそのプログラム記録媒体」に記載されたデバッグシステムのように、デバッグを支援する診断プロセッサを用いる方法がある。
【０００３】
この従来のデバッグシステムは、図２１に示すように、演算プロセッサ群８０１およびメモリ装置８０２と、この演算プロセッサ群８０１の動作状態を監視する診断プロセッサ８０３とを備えている。そして、診断プロセッサ８０３は、演算プロセッサ群８０１を構成する各演算プロセッサがストール状態になったことを検出するストール検出手段８３１と、演算プロセッサの内部状態を採集する採集手段８３２と、演算プロセッサの内部状態をメモリ装置８０２に保存する書込み手段８３４と、メモリ装置８０２に演算プロセッサの内部状態を保持したまま情報処理システムを初期化する初期化手段８３６とで構成される。
【０００４】
このような構成を有する従来のプロセッサ情報収集装置は次のように動作する。まず演算プロセッサ群８０１を構成する各演算プロセッサがストール状態になったことをストール検出手段８３１により検出し、ストールが発生した場合、演算プロセッサの内部状態を採集手段８３２により採集する。そして、採集された演算プロセッサの内部状態を書込み手段８３４により、演算プロセッサの内部状態８２１としてメモリ装置８０２に書き込み、メモリ装置８０２に演算プロセッサの内部状態を保持したまま情報処理システムを初期化する。このため、初期化後もメモリ装置８０２上に演算プロセッサの内部状態が保存されており、この情報を用いることで、ストールが発生した状況についてのデバッグ作業を行うことができる。
【０００５】
しかし、この特許文献１に記載の従来技術のように、診断プロセッサ８０３というデバッグのための高機能な専用ハードウェアをシステムに搭載する手法は、デバッグを効率化する効果をもたらすものの、通常動作に寄与しないハードウェアの追加が必要となり、システムのコストが増加するという弊害がある。また、特に組込み機器ではコストに対する要求が厳しく、専用ハードウェアの搭載が許容されないことが多い。
【０００６】
一方で、半導体集積回路の微細化や、要求される機能の高度化に伴い、システムＬＳＩに複数のＣＰＵなどの実行ユニットが搭載されることが増えてきている。そこで、デバッグ専用ハードウェアによるコストの増加を避けつつ、デバッグを効率化する従来技術例として、特許文献２に記載の「マルチＣＰＵのリセット回路およびリセット方法」がある。
【０００７】
この従来のデバッグシステムは、図２２に示すように、複数のＣＰＵ（ＣＰＵ−Ａ９０１、ＣＰＵ−Ｂ９０２）を内蔵するシステムＬＳＩのリセットおよび割り込みを制御するＣＰＵ制御回路９０３を備え、このＣＰＵ制御回路９０３が、複数のＣＰＵ（ＣＰＵ−Ａ９０１、ＣＰＵ−Ｂ９０２）のうちの一つを、通常動作用のプログラムをデバッグプログラムに置き換えたデバッグ手段に設定する機能を有する。
【０００８】
このような構成を有する従来のデバッグシステムの動作について、図２３を参照して説明する。
【０００９】
まず、ＣＰＵ制御回路９０３がハードウェアリセットを検知すると、デバッグ制御回路９０７が、内部の各機能ブロック（図示せず）にリセットを発行する（ステップＳ９１）。
【００１０】
次にストラップ取込み回路９０６が、ストラップ設定手段９０８からのストラップ等の外部設定情報を読み込む（ステップＳ９２）。
【００１１】
読み込んだストラップ情報が通常動作を示している場合（ステップＳ９３、Ｎｏ）、デバッグ制御回路９０７が、読み込んだストラップ情報に基づきＣＰＵ−Ａ９０１およびＣＰＵ−Ｂ９０２と各機能ブロックのリセットを解除する（ステップＳ９４）。
【００１２】
リセットが解除されると、各機能ブロックは動作を開始する（ステップＳ９５）。
【００１３】
一方、読み込んだストラップ情報がデバッグを指定していると（ステップＳ９３、Ｙｅｓ）、デバッグ処理に入る（ステップＳ９６）。
【００１４】
ここで、デバッグ制御回路９０７によるデバッガの選定結果がデバッガとしてＣＰＵ−Ｂ９０２を選定していると（ステップＳ９６１、Ｂ）、デバッグ制御回路９０７がストラップにより選択されたＣＰＵ−Ｂ９０２のリセットを解除する（ステップＳ９６２）。
【００１５】
その後デバッガＣＰＵ−Ｂ９０２が起動し（ステップＳ９６３）、立ち上がり動作が完了すると（ステップＳ９６４）、ターゲット側ＣＰＵ−Ａ９０１および各機能ブロックをリセット解除する（処理ステップＳ９６５）。
【００１６】
判断結果がデバッガとしてＣＰＵ−Ａ９０１を選定していると（ステップＳ９６１、Ａ）、処理ステップＳ９６６において、デバッグ制御回路７がストラップにより選択されたＣＰＵ−Ａ９０１のリセットを解除する。
【００１７】
その後デバッガＣＰＵ−Ａ９０１が起動し（処理ステップＳ９６７）、立ち上がり動作が完了すると（ステップＳ９６８）、ターゲット側ＣＰＵ−Ｂ９０２および各機能ブロックのリセットを解除する（処理ステップＳ９６９）。
【００１８】
複数の実行ユニットで協調動作するプログラムのデバッグを行う場合、複数の実行ユニット間の通信について、通信に関連する実行ユニット以外の外部から確認できる情報や、不具合発生時の情報を保存しておいて、後から確認する方法では十分な原因追求ができないことが多い。このため、通常動作プログラムが生成する送信内容を擬似的に生成するプログラム、送受信内容をデバッグ作業者に通知するプログラムを利用すると効果的なことが多いため、通信を行うＣＰＵ上でこれらのデバッグ用プログラムを動作させてデバッグ作業を行うことがある。
【００１９】
一方で、これらのデバッグ用プログラムを事前に動作させておくと、ＣＰＵ負荷や記憶領域の使用により通常動作プログラムの動作タイミングなどに影響が出るため、デバッグ用プログラムの存在によって通常動作で生じる可能性がある不具合が発生しない、またこの逆に通常動作プログラムのみの実行では発生しないはずの不具合が生じるなどの弊害がある。
【００２０】
また、複数ユニットが連携して動作するプログラムにおいて、特にタイミングに起因する不具合では不具合がどのユニットで発生するかが一意に定まらず、想定することは困難である。ここで、ストール状態になってしまったり、ＣＰＵの動作に影響が出る不具合が発生した場合、ストール状態になったり、動作に影響を受けたＣＰＵ上のデバッグ用プログラムが使用できないことがあるため、別ＣＰＵ上でデバッグ用プログラムを動作させて使用する必要があるが、不具合発生状況が一意に定まらない不具合では影響を受けないＣＰＵを決定しておくことができない。しかし、特許文献２に記載の従来手法では、リセット時にデバッグ用プログラムを起動する実行ユニット（デバッグ用ＣＰＵ）を割り当てることを特徴としており、デバッグ用ＣＰＵを変更する場合には再度リセットを行う必要がある。このため、割り当てられたデバッグ用ＣＰＵの動作に影響を及ぼす不具合が発生した場合、その状況をデバッグすることができない。
【特許文献１】特開平１１−１８４７３６号広報
【特許文献２】特開２００４−１６４１１３号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、上記の従来のデバッグシステムでは、複数の実行ユニット（ＣＰＵ）が連携して動作するシステムにおいてデバッグを行う際、下記のような問題が発生する。
（１）予めデバッグ用プログラムを起動させておくと通常動作プログラムのみを動作させた場合と動作タイミングが異なってしまい、デバッグ用プログラムの存在によって通常動作で生じる可能性がある不具合が発生しない、またこの逆に通常動作プログラムのみの実行では発生しないはずの不具合が生じる。
（２）デバッグ用プログラムを実行させる実行ユニットを予め設定しておく必要があるが、設定された実行ユニットの動作に影響を及ぼす不具合が発生した場合、その状況をデバッグすることができなくなる。
【００２２】
本発明は上記の問題点に鑑みなされたもので、複数の実行ユニットが連携して動作するシステムにおいて、任意の実行ユニット上に任意のタイミングでデバッグ用プログラムを起動して、デバッグ作業を行うことを可能にするデバッグシステムおよびデバッグ方法を提供することを目的とする。
【課題を解決するための手段】
【００２３】
上記目的を達成するために、本発明のデバッグシステムは、複数の実行ユニットが連携して動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグシステムであって、
前記複数の実行ユニット毎に設けられ、デバッグ用プログラムの起動を指示するデバッグ用プログラム起動指示を受信すると、当該デバッグ用プログラム起動指示により指定されている実行ユニットに対して受信した前記デバッグ用プログラム起動指示を振り分ける起動指示振り分け手段と、
前記複数の実行ユニット毎に設けられ、前記起動指示振り分け手段により振り分けられたデバッグ用プログラム起動指示に基づいて、指定された実行ユニット上にデバッグ用プログラムを起動する複数のデバッグ用プログラム起動手段とを備え、
前記各実行ユニット上において、割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラによって他の実行ユニットからの割り込みが発生した際に、通常動作プログラムにより実行されたプロセスであって暴走している前記プロセスを停止させるプロセス制御手段と、前記プロセス制御手段によるプロセス制御が行われた後、得られたレジスタ、キャッシュメモリ、フラッシュメモリを含む予め設定されたメモリ内の情報を、前記割り込みを発生させた前記他の実行ユニットに対して送信する応答生成手段とが実現され、
前記各実行ユニットのいずれかにおいて起動されるデバッグ用プログラムによって、デバッグ対象の実行ユニットに対して割り込みを発生させる実行ユニット間割り込み生成手段と、デバッグ対象の前記実行ユニットにおける応答生成手段からの応答を受信する応答受信手段とが実現されている。
【００２４】
本発明によれば、デバッグ用プログラムを起動するためのデバッグ用プログラム起動手段を各実行ユニット毎に設け、このデバッグ用プログラム起動手段により、起動指示振り分け手段により振り分けられた起動指示に基づいてデバッグ用プログラムの起動を行うようにしている。そのため、通常動作プログラムのみを動作させた状態で不具合が確認された場合であっても、任意のタイミングで不具合の発生原因となる処理を行っている実行ユニットに対してデバッグ用プログラムを起動してデバッグ作業を行うことが可能となる。
【００２５】
さらに、本発明では、デバッグ対象実行ユニットによって実行される割り込みハンドラ内にプロセス制御手段を導入し、割り込みハンドラ内からデバッグ対象プロセスの制御を行うよう構成する。そして、デバッグ対象実行ユニット以外の実行ユニット上で動作しているデバッグ用プログラムから、デバッグ対象実行ユニットに割り込みを発生させ、割り込みハンドラ内でプロセス制御を行うことにより、暴走したプロセスが存在する場合であっても、暴走しているプロセスを停止させ正常動作に復帰させることが可能となる。
【発明の効果】
【００２６】
以上説明したように、本発明は、デバッグ用プログラム起動指示振り分け手段と、デバッグ用プログラム起動手段を備えることにより、任意のタイミングで任意の実行ユニット上にデバッグ用プログラムを起動できるよう構成されていることにより、通常動作プログラムのみを実行した状態で不具合を発生させるか、その直前まで進め、その後、不具合の発生原因となる処理を行っている実行ユニット上にデバッグ用プログラムを起動し、デバッグ作業を行うことが可能になるという効果を得ることができる。
【発明を実施するための最良の形態】
【００２７】
次に、本発明の実施形態について図面を参照して詳細に説明する。
【００２８】
（第１の実施形態）
先ず、本発明の第１の実施形態のデバッグシステムを、図面を参照して説明する。本実施形態のデバッグシステムは、図１に示すように、２個の実行ユニットＡ、Ｂと、通信ポート１と、ＲＡＭ（Random Access Memory）等により構成され書き換え可能な記憶手段２と、ＨＤＤ（Hard Disk Drive）装置等により構成され各種プログラムが格納されたプログラム格納手段３とを備えている。そして、記憶手段２の記憶領域は、実行ユニットＡ用プログラム領域６と、実行ユニットＢ用プログラム領域７とから構成されている。
【００２９】
実行ユニットＡ用プログラム領域６には、図２に示されるように、デバッグ用プログラム起動指示振り分け手段（図２中では、振り分け手段と表示する。）６１と、デバッグ用プログラム起動手段（図２中では、起動手段と表示する。）６２と、デバッグ用プログラム６３と、通常動作プログラム６４とが格納され、これらを実行ユニットＡ上で実行されるプログラムとして構成する。
【００３０】
また、実行ユニットＢ用プログラム領域７にも、図２に示されるように、デバッグ用プログラム起動指示振り分け手段７１と、デバッグ用プログラム起動手段７２と、デバッグ用プログラム７３と、通常動作プログラム７４とを備え、これらを実行ユニットＢ上で実行されるプログラムとして構成する。
【００３１】
ここで、デバッグ用プログラム起動指示振り分け手段６１、７１やデバッグ用プログラム起動手段６２、７２は、記憶手段２内では単にプログラムとして記憶されていて、実行ユニットＡ、Ｂ上で起動されて初めて各種の動作を行うものであるが、説明を簡単にするためにデバッグ用プログラム起動指示振り分け手段６１、７１やデバッグ用プログラム起動手段６２、７２が独自に各種の動作を行うものとして説明する。
【００３２】
これらの各種プログラムは、プログラム格納手段３から記憶手段２に読み込まれ、記憶手段２上の所定の領域に記憶される。
【００３３】
デバッグ用プログラム起動指示振り分け手段６１、７１は、通信ポート１より送られてくるデバッグ用プログラムの起動指示（以下、単に起動指示と称する。）を受信すると、この起動指示により指定されている実行ユニットに対して受信したデバッグ用プログラムを振り分ける。デバッグ用プログラム起動手段６２、７２は、実行ユニットＡ、Ｂ毎に設けられ、起動指示振り分け手段６１、７１により振り分けられた起動指示に基づいて、指定された実行ユニット上にデバッグ用プログラム６３、７３を起動する。
【００３４】
ここで、デバッグ用プログラム起動指示振り分け手段６１は、図３に示すように、通信ポートから起動指示を受信する受信手段６１１と、起動プログラムに起動指示を送信する送信手段６１４と、実行ユニット間通信を用いて他の実行ユニットに起動指示を送信する送信手段６１２と、他の実行ユニットから実行ユニット間通信を用いて送信されてくる起動指示を受信する受信手段６１５と、通信ポートの通信対象実行ユニットを変更する通信対象変更手段６１３を備える。
【００３５】
また、デバッグ用プログラム起動指示振り分け手段７１も同様に、受信手段７１１と、送信手段７１４と、送信手段７１２と、受信手段７１５と、通信対象変更手段７１３とを備えている。
【００３６】
次に、図２及び図４のフローチャートを参照して本実施形態の全体の動作について詳細に説明する。
【００３７】
まず、外部の制御端末（図示せず）において入力された起動指示が、通信ポート１に対して送られてくる。この起動指示には、デバッグ用プログラムを起動する実行ユニットを指定する符号と、起動するデバッグ用プログラムの種別を指定する符号とが含まれる。ここでデバッグ用プログラム起動指示振り分け手段６１、７１が、デバッグ用プログラム起動指示を通信ポート１から受信すると（図４のステップＳ１）、起動指示で指定されている、デバッグ用プログラムを起動する実行ユニットに対して起動指示を振り分け、デバッグ用プログラム起動手段６２、７２に起動指示を発行する（ステップＳ２）。その後デバッグ用プログラム起動手段６２、７２がデバッグ用プログラム６３、７３の起動を行う（ステップＳ３）。
【００３８】
ここで、デバッグ用プログラム６３、７３が通信ポート１よりコマンドを受信（ステップＳ４）すると、デバッグ用プログラム６３、７３により構成される手段であるコマンド解析手段（図示せず）により解析が行われ、受信したコマンドがデバッグコマンドの場合（ステップＳ５、Ｎｏ）は、コマンドに応じた作業内容を実行し、デバッグ作業を行う。ここで、作業内容によっては通信ポート１を通じてデータの送受信を行うこともある。通信ポート１より受信したコマンドが終了コマンドであった場合（ステップＳ５、Ｙｅｓ）には、デバッグ用プログラム６３、７３は、デバッグを終了する。
【００３９】
ここで、コマンド解析手段とは、受信したコマンドの内容を解析するための手段であり、デバッグ用プログラム６３、７３により構成される手段である。また、コマンドの種類としては、上述した終了コマンド以外にも、メモリやレジスタの内容を読み込んだり、メモリやレジスタにある値を書き込んだりするコマンドが存在する。
【００４０】
次に、図３及び図５のフローチャートを参照して本実施形態の、デバッグ用プログラム起動指示振り分け手段６１、７１の動作について詳細に説明する。ここでは、通信ポート１の割り込み先の初期値を実行ユニットＡとして説明する。まず、デバッグ用プログラム起動指示が通信ポートより送られてきた場合、実行ユニットＡに割り込みが発生し（ステップＳ１１）、起動指示振り分け手段６１が起動する。その後、受信手段６１１が通信ポート１からの起動指示を受信し（ステップＳ１２）、その宛先を判定する。ここで宛先が実行ユニットＡであった場合（ステップＳ２１、Ｙｅｓ）には送信手段６１４により、実行ユニットＡのデバッグ用プログラム起動手段６２に対して起動指示を送信する（ステップＳ２２）。宛先が実行ユニットＢであった場合（ステップＳ２１、Ｎｏ）には、ユニット間通信を用いる送信手段６１２により実行ユニットＢに対して起動指示を送信する（ステップＳ２３）。次に実行ユニットＢ側の起動指示振り分け手段７１が、受信手段７１５によりこの起動指示を受信すると（ステップＳ２４）、通信対象変更手段７１３によって通信ポートの通信対象を実行ユニットＢに変更し（ステップＳ２５）、送信手段７１４により、実行ユニットＢのデバッグ用プログラム起動手段７２に対して起動指示を送信する。
【００４１】
なお、通信ポート１からデバッガ起動指示を受け取る他に、タイマなどを用いて起動指示を与えることにより一定時間経過後にデバッグ用プログラムを起動させ、その時点での状況を確認するよう構成することもできる。また、ブレイクポイントを設定する方法、ある地点に到達した時にデバッグ対象プログラム自身が起動指示を発行する方法などにより、プログラムの特定地点への到達によって起動することとしてもよい。
【００４２】
また、本実施形態では２個の実行ユニットを備えるシステムについて記載しているが、３個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【００４３】
さらに、本実施形態では、デバッグ用プログラムを起動する実行ユニットは予め指定されていて、デバッグ用プログラム起動指示振り分け手段６１、７１は指定された実行ユニットに対して起動指示を振り分けるものとして説明していたが、デバッグ用プログラムを起動する実行ユニットを自動的に選択するよう構成することもできる。例えば、デバッグ用プログラム起動指示振り分け手段６１、７１は、実行ユニットＡ、Ｂの動作状況に基づいて定められる実行ユニットに対応したデバッグ用プログラム起動手段に起動指示が送られるように構成することができる。ここで、実行ユニットの動作状況とは、例えば、各実行ユニットが利用する記憶領域の空き容量や、実行ユニット間の連携の状態等を示している。
【００４４】
空き容量に基づいて振り分け先を選択する場合、各実行ユニットＡ、Ｂが利用する記憶領域の空き容量を検出するように起動指示振り分け手段６１、７１を構成し、検出された空き容量に余裕がある実行ユニットに対応したデバッグ用プログラム起動手段に起動指示を振り分けるように構成する。このような構成とする場合、各実行ユニットＡ、Ｂ上の起動指示振り分け手段６１、７１が空き容量の検出を行い、その他の実行ユニットに対して空き容量を通知するよう構成する方式や、各実行ユニットＡ、Ｂ上の起動指示振り分け手段６１、７１が、他の実行ユニットが利用する記憶領域を直接参照して、単独で空き容量を検出するよう構成する方式などがある。
【００４５】
また、本実施形態では一例として２個の実行ユニットＡ、Ｂが連携して動作を行うシステムを用いて説明しているが、３個以上の実行ユニットで連携を行いながら動作するプログラムをデバッグ対象とする場合には、その連携の状態を把握して起動指示の振り分け先を決定することもできる。
【００４６】
この場合には、先ず、各プログラムが他のプログラムとの通信経路を確保したことを検出するよう起動指示振り分け手段を構成し、デバッグの対象とする連携して動作しているプログラムとの関係が無い、もしくは関係が少ない実行ユニット上に起動指示を振り分けるよう構成することができる。ここで、通信経路の確保の検出には、プログラムが通信経路を確保する関数呼び出しを行ったことを検出する方法、通信経路のステータスが保存されている記憶領域を観測する方法などをとることができる。
【００４７】
その逆に、デバッグ対象のプログラムが別の実行ユニット上で動作しているプログラムと連携している場合、デバッグ対象のプログラムが動作している実行ユニットだけでなく、その連携先の実行ユニットに対しても起動指示を振り分け、連携するプログラムをまとめてデバッグ対象とするよう構成することもできる。
【００４８】
次に、本実施形態のデバッグシステムの効果について説明する。
【００４９】
本実施形態では、デバッグ用プログラム起動指示振り分け手段６１、７１と、デバッグ用プログラム起動手段６２、７２を実行ユニットＡ、Ｂ上のソフトウェアとして構成し、起動指示受信後にデバッグ用プログラムをいずれかの実行ユニット上で起動するよう構成されているため、デバッグ用ハードウェアによるコスト増加なしにデバッグ作業の効率化を図ることができる。
【００５０】
また、本実施形態では、さらに、デバッグ用プログラム起動指示振り分け手段６１、７１と、デバッグ用プログラム起動手段６２、７２を備えることにより、任意のタイミングで任意の実行ユニット上にデバッグ用プログラムを起動することが可能となる。その結果、通常動作プログラムのみを実行した状態で不具合を発生させるか、その直前まで進め、その後、不具合の発生原因となる処理を行っている実行ユニット上にデバッグ用プログラムを起動し、デバッグ作業を行うことが可能である。
【００５１】
また、タイマなどを用いて起動指示を与えるよう構成し、一定時間経過後に起動するよう構成することで、作業者が起動指示を入力する方法で生じる、デバッグ用プログラムを起動するタイミングがばらつく影響を排除することや、高い時間精度で起動時間を調整することが可能となる。
【００５２】
また、ブレイクポイントを設定する方法、ある地点に到達した時にデバッグ対象プログラム自身が起動指示を発行する方法などにより、プログラムの特定地点への到達によって起動するよう構成することで、起動時間を調整するのみでは困難な、観測を行いたい地点への到達時間が条件により一定でない場合についても、観測を行いたい地点においてデバッグ用プログラムを起動することが可能となる。
【００５３】
更に、既に動作している通常動作プログラムによって記憶領域が使用されており、デバッグ用プログラムを追加で起動できない場合がある。一方で、デバッグ用プログラムには、どの実行ユニットで起動してもデバッグ作業を行えるタイプのものがある。このような場合に、各実行ユニットの記憶領域の空き容量を検出し、空き容量に余裕がある実行ユニットに対して起動指示を振り分けるよう構成することで、空き容量不足でデバッグ用プログラムが起動できない実行ユニットを避けて起動指示を発行することができる。
【００５４】
また、連携して動作しているプログラムが実行されている実行ユニット上でデバッグ用プログラムを起動すると、連携しているプログラムの動作に影響を与えることがあり、デバッグ作業に支障をきたすことがある。この場合、連携の状態を把握して起動指示を発行するよう構成することで、連携して動作しているプログラムが実行されている実行ユニットとは異なる実行ユニット上にデバッグ用プログラムを起動することができる。
【００５５】
（第２の実施形態）
次に、本発明の第２の実施形態のデバッグシステムについて図面を参照して詳細に説明する。
【００５６】
上記で説明した第１の実施形態は、通信ポートの通信対象実行ユニットを変更できるシステムに対して本発明を適用した場合であった。しかし、システムによっては、通信ポートの通信対象実行ユニットを変更できない、つまり通信ポートの通信対象実行ユニットが固定されているようなシステムも存在する。このようなシステムに対して本発明を適用した場合、デバッグ用プログラム起動指示振り分け手段を各実行ユニットに対して設けたとしても、通信ポートの通信対象となっていない実行ユニット上で起動されたデバッグ用プログラムに対してコマンドを送信することができない。本発明の第２の実施形態は、このようなシステムに対して本発明を適用した場合である。
【００５７】
本発明の第２の実施形態は、図１に示された第１の実施形態における構成に加えて、図６のように、新たに他の実行ユニットで実行されるデバッグ用プログラムの通信を中継する中継手段６５を備える。
【００５８】
中継手段６５は、２つの実行ユニットＡ、Ｂのうちの実行ユニットＡ上において構成され、通信ポート１からデバッグ用プログラム６３、７３に対して送信されるコマンドを指定された実行ユニット上のデバッグ用プログラムに対して中継する。
【００５９】
本実施形態における通信ポート１は、通信対象実行ユニットは実行ユニットＡに固定されている。そして、中継手段６５は、通信ポート１からのコマンドの宛先が実行ユニットＡの場合には、そのコマンドを実行ユニットＡのデバッグ用プログラム６３に送信し、通信ポート１からのコマンドの宛先が実行ユニットＢの場合には、そのコマンドを実行ユニットＢのデバッグ用プログラム７３に送信する。
【００６０】
本実施形態における起動指示振り分け手段６１、７１では、図３に示した起動指示振り分け手段６１、７１のうち、通信対象変更手段６１３、７１３、実行ユニットＡ側のユニット間通信受信手段６１５、実行ユニットＢ側の、ユニット間通信送信手段７１２、通信ポートからの通信受信手段７１１を省略することができる。
【００６１】
本実施形態における全体の動作は、本発明の第１の実施形態と同一であり、起動指示振り分け手段６１、７１の動作は、図５における通信ポートの通信対象を変更するステップがないことを除いて本発明の第１の実施形態と同一である。
【００６２】
また、本実施形態では２個の実行ユニットを備えるシステムについて記載しているが、３個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【００６３】
次に、本実施形態のデバッグシステムの効果について説明する。
【００６４】
本実施形態では、デバッグ用プログラム６３、７３への通信を中継する中継手段６５を実行ユニットＡ用プログラム領域６に構成し、実行ユニットＢで実行されるデバッグ用プログラム７３の通信を中継するように構成されているため、通信ポート１の通信対象実行ユニットが実行ユニットＡに固定され変更できないようなシステムにおいても本発明を適用することが可能となる。また、通信ポート１と直接通信していない実行ユニットＢ上のデバッグ用プログラム７３も中継手段６５によって通信が可能となるため、複数の実行ユニットＡ、Ｂで同時に複数のデバッグ用プログラム６３、７３を利用することが可能となる。
【００６５】
（第３の実施形態）
次に、本発明の第３の実施形態のデバッグシステムについて図面を参照して詳細に説明する。
【００６６】
本実施形態のデバッグシステムは、第１の実施形態のデバッグシステムと同様に、通信ポートの通信対象実行ユニットの変更が可能なシステムに対して本発明を適用したものである。通信ポートの通信対象実行ユニットの変更が可能なシステムでは、デバッグ用プログラムに対するコマンドは、通信ポートの切り替えを行うことにより送信することが可能である。しかし、複数のデバッグ用プログラムを同時に起動させるような場合、通信ポートの切り替えが煩雑に発生することが予想される。しかし、通信ポートの通信対象実行ユニットを変更する処理には、ある程度のオーバヘッドが必要となる。そのため、通信ポートの通信対象実行ユニットを変更可能な場合であっても、図６に示した第２の実施形態のデバッグシステムにおける中継手段を用いて、デバッグ用プログラムへの各種コマンドを中継したほうが通信ポートを切り替える処理が不要となり処理の軽減を図ることが可能となる。
【００６７】
しかし、この中継手段をある特定の実行ユニットにしか備えないような構成を採用した場合、中継手段が設けられた実行ユニットがストール状態となると、中継手段自体も機能しなくなってしまう。そのため、本実施形態のデバッグシステムでは、どの実行ユニットがストール状態になった場合でも、デバッグ用プログラムへの各種コマンドを中継することが可能なように、中継手段を各実行ユニット毎に設けるようにする。
【００６８】
本実施形態では、説明の都合により、３つの実行ユニットＡ、Ｂ、Ｃが存在するシステムに対して本発明を適用した場合として説明する。
【００６９】
本発明の第３の実施形態は、図１に示された第１の実施形態における構成に加えて、図７のように、実行ユニットＣ用プログラム領域８が新たに追加され、他の実行ユニットで実行されるデバッグ用プログラムの通信を中継するための実行ユニットＡ側の中継手段６５、実行ユニットＢ側の中継手段７５、実行ユニットＣ側の中継手段８５が追加された構成となっている。
【００７０】
本実施形態における中継手段６５、７５、８５は、３つの実行ユニットＡ、Ｂ、Ｃ上においてそれぞれ構成され、通信ポート１からデバッグ用プログラム６３、７３、８３に対して送信されるコマンドを指定された実行ユニット上のデバッグ用プログラムに対して中継する。
【００７１】
実行ユニットＣ用プログラム領域８は、図７に示されるように、デバッグ用プログラム起動指示振り分け手段８１と、デバッグ用プログラム起動手段８２と、デバッグ用プログラム８３と、通常動作プログラム８４とを備え、これらを実行ユニットＣ上で実行されるプログラムとして構成する。
【００７２】
本実施形態における起動指示振り分け手段６１、７１の動作は、本発明の第１の実施形態と同様である。また、起動指示振り分け手段８１の動作は、起動指示振り分け手段６１、７１と同様である。ただし、起動指示振り分け手段６１、７１、８１の動作における通信ポート１の通信対象を変更するステップについては、２つ目以降のデバッグ用プログラムを起動する場合には、切り替えが無駄であることも考えられるため、これを利用しないこととして構成してもよい。
【００７３】
また、本実施形態では３個の実行ユニットを備えるシステムについて記載しているが、４個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【００７４】
次に、本実施形態のデバッグシステムの効果について説明する。
【００７５】
本実施形態では、デバッグ用プログラムへの通信を中継する中継手段６５、７５、８５を各実行ユニットＡ、Ｂ、Ｃ毎に備えるようにし、他の実行ユニットで実行されるデバッグ用プログラムの通信をいずれの実行ユニットでも中継可能なように構成されている。そのため、ある実行ユニットがストール状態になった場合でも、通信ポート１の通信対象実行ユニットの煩雑な切り替えを不要としつつ複数の実行ユニットで同時に複数のデバッグ用プログラムを利用することができる。
【００７６】
例えば、図７に示した本実施形態のデバッグシステムにおいて、３つのデバッグ用プログラム６３、７３、８３をそれぞれ起動した場合を用いて説明する。図７の例では、通信ポート１の通信対象実行ユニットとして実行ユニットＡが設定されているため、実行ユニットＡに対して備えられた中継手段６５を経由して、デバッグ用プログラム６３、デバッグ用プログラム７３、デバッグ用プログラム８３に対して各種コマンドが中継されている。ここで、実行ユニットＡが何等かの理由によりストール状態となってしまった場合、中継手段６５も機能しなくなってしまう。そのため、ここで通信ポート１の通信対象実行ユニットを実行ユニットＡから実行ユニットＢに変更し、実行ユニットＢに対して設定されている中継手段７５を経由して、デバッグ用プログラム７３、８３への各種コマンドの中継を行うようにすれば、デバッグ用プログラム７３との通信においては実行ユニットＢ、デバッグ用プログラム８３との通信においては実行ユニットＣへというような、各通信毎に通信ポート１における通信対象実行ユニットの煩雑な切り替えを必要とすることなく、２個の実行ユニットＢ、Ｃで同時にデバッグ用プログラムの起動を行うことが可能となる。
【００７７】
（第４の実施形態）
次に、本発明の第４の実施形態のデバッグシステムについて図面を参照して詳細に説明する。
【００７８】
上記第１から第３の実施形態では、指定された実行ユニットまたは起動指示振り分け手段により選択された実行ユニットに対して、デバッグ用プログラム起動指示が振り分けられるようにしたものである。しかし、デバッグ用プログラムを起動しようとした実行ユニットが既にストール状態となっていて、デバッグ用プログラムの起動が不可能な場合がある。本発明の第４の実施形態のデバッグシステムは、このような弊害の発生を防ぐため、デバッグ用プログラムを起動可能な実行ユニットを選定する際に、ストール状態となってデバッグ用プログラムの起動が不可能な実行ユニットが選択されないようにしたものである。
【００７９】
本発明の第４の実施形態は、図１に示された第１の実施形態における構成に加えて、図８に示すように、ストールしている実行ユニットを避けて、プログラムを実行可能な実行ユニットの起動指示振り分け手段に起動指示が送られるよう設定するストール発生実行ユニット回避手段（図８中では、回避手段と表示する。）６６、７６を備える。
【００８０】
ストール発生実行ユニット回避手段６６、７６は、デバッグ用プログラムを起動可能な複数の実行ユニットＡ、Ｂに対してそれぞれ配置されている。そして、ストール発生実行ユニット回避手段６６、７６は、起動指示がストール状態の実行ユニットに対して送られないような処理を行っている。
【００８１】
具体的には、実行ユニットＡのストール発生実行ユニット回避手段６６は、起動指示振り分け元実行ユニット（つまり、通信ポート１の通信対象実行ユニット）を実行ユニットＡににするよう通信ポート１に対して通知し、実行ユニットＢのストール発生実行ユニット回避手段７６は、起動指示振り分け元実行ユニットを実行ユニットＢににするよう通信ポート１に対して通知する。
【００８２】
図１のように２個の実行ユニットＡ、Ｂを備えるシステムでは、実行ユニットＡ、Ｂ、Ａ、Ｂ…のように交互に、３個以上の場合にはそれぞれ順番に、タイマを利用するか、通常動作時に利用されているタイマ割り込みハンドラ内のプログラムによってストール発生実行ユニット回避手段６６、７６が実行されるよう構成する。なお、ストール発生実行ユニット回避手段６６、７６の具体的な実現方法は、交互に起動したり、順番に起動する必要は必ずしもないが、後述する不具合検出・起動指示生成手段との組み合わせを効果的に行うために、このように構成することが望ましい。
【００８３】
タイマ割り込みハンドラとは、タイマ割り込みが発生した場合に、その割り込みを処理するために最初に起動されるプログラムのことである。このタイマ割り込みハンドラは、タイマ割り込み機能を備えた実行ユニットであれば一般的に使用されるプログラムである。
【００８４】
本実施形態における全体の動作については、図４のフローチャートにおける起動指示受信前に、デバッグ用プログラムを起動可能な実行ユニットを選定するステップが追加されることを除いて本発明の第１の実施形態と同一である。
【００８５】
次に、ストール発生実行ユニット回避手段６６、７６の動作について図９を参照して詳細に説明する。
【００８６】
図９において、ステップＳ７１とステップＳ７４は意図的に選択するものではなく、その時点での状況によって必然的に選択される事項である。つまり、ステップＳ７１の分岐は、ステップＳ７２は実行ユニットＡによって実行される処理であるが、実行ユニットＡがストールしている場合はプログラムが実行されないため、この処理が行われずにステップＳ７３に進んでしまうことを示す。同様に、ステップＳ７４の分岐は、ステップＳ７５は実行ユニットＢによって実行される処理であるが、実行ユニットＢがストールしている場合はこの処理が行われずにステップＳ７６に進んでしまうことを示す。
【００８７】
ここでは、デバッグ用プログラム起動指示の振り分け元となる（通信ポートの通信対象となる）実行ユニットの初期値をＢとして説明する。まず、ステップＳ７１の段階で、実行ユニットＡがストールしていない場合（ステップＳ７１、Ｎｏ）、実行ユニットＡ上のストール発生実行ユニット回避手段６６が、デバッグ用プログラム起動指示の振り分け元となる起動ユニットの設定値を実行ユニットＡに変更する（ステップＳ７２）。この処理は、通信ポート１の通信対象を変更することで行われる。ここで起動指示があった場合（ステップＳ７３、Ｙｅｓ）、設定された実行ユニット（ここでは実行ユニットＡ）へ起動指示が送信される（ステップＳ７７）。
【００８８】
一方ステップＳ７３で起動指示がなかった場合（ステップＳ７３、Ｎｏ）、実行ユニットＢがストールしていなければ（ステップＳ７４、Ｎｏ）、実行ユニットＢ上のストール発生実行ユニット回避手段７６が、デバッグ用プログラム起動指示の振り分け元となる起動ユニットを実行ユニットＢに変更する（ステップＳ７５）。ここで起動指示があった場合（ステップＳ７６、Ｙｅｓ）、設定された実行ユニット（ここでは実行ユニットＢ）へ起動指示が送信される（ステップＳ７７）。起動指示がない場合（ステップＳ７６、Ｎｏ）は初めに戻る。
【００８９】
ここで、ステップＳ７１の段階で実行ユニットＡがストールしていた場合、ステップＳ７２の処理が行われずにステップＳ７３に進むが、ここで起動指示があった場合、デバッグ用プログラム起動指示の振り分け元である起動ユニットは実行ユニットＢであるため、ストールした実行ユニットＡにデバッグ用プログラム起動指示が送信され、起動ができなくなる状況を避けることができる。ステップＳ７４の段階で実行ユニットＢがストールしていた場合も同様の仕組みにより実行ユニットＢにデバッグ用プログラム起動指示が送信され、起動ができなくなる状況を避けることができる。
【００９０】
この方法は実行ユニットが３個以上の場合でも容易に拡張可能であり、実行ユニットのいずれかが動作していれば動作している実行ユニットに対してデバッグ用プログラム起動指示の振り分け元となるよう設定される。
【００９１】
ただし、次の場合について注意が必要である。一つの注意点は、ステップＳ７２においてデバッグプログラム起動指示の振り分け元となる起動ユニットを実行ユニットＡに変更した後、ステップＳ７３において起動指示を受け取る前に実行ユニットＡがストールする場合である。これは、ステップＳ７５とステップＳ７６の間においても同様である。この場合、デバッグプログラム起動指示が受理されないが、一定時間を経過すると、ストールしていない実行ユニットによって起動指示の振り分け元となる起動ユニットが変更されるため、起動に失敗した場合には一定時間後に起動指示を再発行するよう構成することが望ましい。また、全ての実行ユニットがストールした場合に備えて、一定回数の再発行によって起動しない場合は処理を終了し、エラー報告をするよう構成してもよい。
【００９２】
他の注意点は、これまでの手法により振り分け手段までの実行は可能であるものの、起動指示で指定しているデバッグ用プログラムを起動する実行ユニットが、ストールしている実行ユニットである場合に起動できないことである。この場合について、一定時間後に起動が確認できない場合はエラー報告をするよう構成してもよいが、後述する不具合検出・起動指示生成手段の不具合検出手法によってストールを検出し、起動できないと判定されている場合には即座にエラー報告をし、別の実行ユニットでデバッグ用プログラムを起動するなどの手法を用いることが望ましい。
【００９３】
また、起動する実行ユニットを別途指定する必要がないように、後述する、デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象実行ユニットに関わる記憶領域を参照することで、デバッグ対象実行ユニットや対象実行ユニットで動作しているプログラムの状態を解析するデバッグ用プログラムを起動するなど、起動指示振り分け元の実行ユニット上にデバッグ用プログラムを起動するよう構成することが望ましい。この場合は、起動指示を他の実行ユニットに対して転送する、起動指示振り分け手段の機能を不要とすることもできる。
【００９４】
次に、本実施形態のデバッグシステムの効果について説明する。
【００９５】
本実施形態では、ストール発生実行ユニット回避手段６６、７６により、デバッグ用プログラムを実行不可能な実行ユニットに対して起動指示が送られないように構成されているため、不具合によって実行ユニットがストールする、実行ユニットの動作に影響が出るような場合でも、利用可能な実行ユニットがあれば、その実行ユニット上にデバッグ用プログラムを起動することが可能となる。
【００９６】
（第５の実施形態）
次に、本発明の第５の実施形態について図１０を参照して詳細に説明する。
【００９７】
上記第１から第４のデバッグシステムでは、デバッグ用プログラムは、起動された実行ユニットに関わる記憶領域しか参照することができなかった。しかし、記憶領域をどのように使用しているかを参照することによりデバッグ対象実行ユニットで動作しているプログラムの状態を解析することが可能になる場合がある。本実施形態のデバッグシステムでは、デバッグ対象実行ユニットの記録領域をデバッグ用プログラムが起動された実行ユニットから参照してデバッグ作業を行うことを可能にするものである。
【００９８】
本発明の第５の実施形態は、図２に示した第１の実施形態のデバッグシステムにおいて、デバッグ用プログラム６３、７３を、それぞれデバッグ用プログラム６７、７７に置き換えた構成となっている。
【００９９】
デバッグ用プログラム６７は、状態を解析するための手段として、物理・仮想アドレス変換手段６７１と、情報抽出手段６７２とを備えている。
【０１００】
物理・仮想アドレス変換手段６７１は、仮想アドレスを物理アドレスに変換する。情報抽出手段６７２は、物理・仮想アドレス変換手段６７１により変換された物理アドレスを用い、ＯＳ（Operating System：オペレーティングシステム）などが管理情報をメモリに配置する構造を考慮して、通常動作プログラム７４が使用している記憶領域から必要情報を抽出する。また、デバッグ用プログラム７７も同様に、物理・仮想アドレス変換手段７７１と、情報抽出手段７７２とを備えている。
【０１０１】
本実施形態では実行ユニットＡ上にデバッグ用プログラムを起動する場合を用いて説明を行うが、実行ユニットＢ上にデバッグ用プログラム７７を起動した場合でも同様である。
【０１０２】
物理・仮想アドレス変換手段６７１は、仮想アドレスと物理アドレスのオフセット（差分）情報を加減することにより、仮想アドレスと物理アドレスの相互変換を行う第１の物理・仮想アドレス変換手段と、物理・仮想変換テーブルの情報を解析することにより仮想アドレスと物理アドレスを対応づける第２の物理・仮想アドレス変換手段がある。
【０１０３】
まず第１の物理・仮想アドレス変換について説明する。第１の物理・仮想アドレス変換は、ＯＳのカーネルが静的に確保する領域など、広範囲に渡って連続する物理アドレスが確保されている領域（以後、連続領域とする）に対応するための手段を提供する。
【０１０４】
連続領域において、ある仮想アドレスに対応する物理アドレスが分かった場合に、仮想アドレスと物理アドレスの差分を求めることができる。連続領域では、仮想アドレスをｎ単位増加させた場合に対応する物理アドレスもｎ単位増加したものになる。このため、仮想アドレスと物理アドレスの差分を保持し、これを加減することで、仮想アドレスから物理アドレスへの変換、物理アドレスから仮想アドレスの変換を行うことが可能となる。
【０１０５】
また、この差分は別途計算しておいたものを用いることもできるが、連続領域の先頭に対応する仮想アドレスが、あらかじめ決まっているＯＳがあり、この場合、各ＣＰＵに割り当てられるメモリ領域の先頭の物理アドレス情報を元に差分を計算することが可能となる。このため、デバッグ用プログラム起動時に各ＣＰＵに割り当てられるメモリ領域の先頭の物理アドレス情報を取得可能であるように構成し、自動的に差分を計算可能にすることが望ましい。
【０１０６】
次に、第２の物理・仮想アドレス変換について図１１を用いて説明する。第２の物理・仮想アドレス変換は、高機能ＯＳなどで用いられる、物理・仮想アドレステーブルを用いてユーザプログラムなどの仮想アドレス管理を行う手法に対応するための手段を提供する。ユーザプログラムなどでは、連続する仮想アドレスに対応するメモリ領域が連続しているとは限らず、物理アドレスが差分により一意に決まらないため、複数の手順を要する。
【０１０７】
第２の物理・仮想アドレス変換では、まず第１の物理・仮想アドレス変換を用いて、ＯＳが保持している物理・仮想アドレス変換テーブルの物理アドレスを取得する（ステップＳ１０１）。
【０１０８】
この物理アドレスを用いて物理・仮想アドレス変換テーブルを参照し、その内容を取得する（ステップＳ１０２）。
【０１０９】
高機能ＯＳでは、物理・仮想変換テーブルが複数の層で構成されているものがあり、一度の参照で変換が完了するとは限らない。そのため、変換が完了しない場合（ステップＳ１０３、Ｎｏ）、物理・仮想変換テーブルの内容から次に参照すべき物理・仮想変換テーブルの仮想アドレスを取得する（ステップＳ１０４）。
【０１１０】
これらの処理を繰り返し、目的の物理アドレスが得られた場合（ステップＳ１０３、Ｙｅｓ）、得られた物理アドレスの通知を行い（ステップＳ１０５）、第２の物理・仮想アドレス変換を終了する。
【０１１１】
次に、情報抽出手段６７２について図１２を用いて説明する。
【０１１２】
まず、基点となるデータ構造が存在する仮想アドレスを元に、ステップＳ２０１の物理・仮想アドレス変換を行うことによって参照するデータが存在する物理アドレスを取得する。
【０１１３】
データを直接参照可能なアドレスとしてマッピング可能な場合、参照するデータと同一もしくは類似の構造をもつ構造体変数を該当する物理アドレスにマッピングするなどの方法で必要情報に容易にアクセス可能なように構成し（ステップＳ２０２）、参照する（ステップＳ２０３）。
【０１１４】
もしくは、参照するデータと同一もしくは類似の構造をもつ変数をあらかじめ用意し、得られた物理アドレスを用いて、参照するデータを用意した変数の領域にコピーを行い、参照を行うこととしてもよい。この場合、直接参照できない場合でも利用可能になるが、コピーを行うオーバヘッドが発生するという欠点も生じる。
【０１１５】
データ構造が単純な場合、これらの処理で抽出が終了（ステップＳ２０４、Ｙｅｓ）し、抽出結果を通知（ステップＳ２０６）することで処理が完了するが、データによっては、リスト構造などのデータが分散した状態で配置されているものがある。
【０１１６】
最初の参照で必要データがないか、一部しかそろっていない場合（ステップＳ２０４、Ｎｏ）、次のリストの場所を示すアドレスを取得する（ステップＳ２０５）。このアドレスは仮想アドレスで記載されているため、物理・仮想アドレス変換を行うことによって、物理アドレスを取得し（ステップＳ２０１）、次のリストの内容を参照する（ステップＳ２０２、Ｓ２０３）。この処理を必要なデータが揃うまで複数回繰り返す。
【０１１７】
なお、仮想アドレスを用いるＯＳ以外では、これらの処理のうちステップＳ２０１の物理・仮想アドレス変換は必要がなく、これを除いた処理によって同様の機能を実現することができる。
【０１１８】
また、本実施形態では２個の実行ユニットを備えるシステムについて記載しているが、３個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【０１１９】
本実施形態では、デバッグ用プログラムとして、デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象実行ユニットに関わる記憶領域を参照することで、デバッグ対象実行ユニットや対象実行ユニットで動作しているプログラムの状態を解析するデバッグ用プログラムを備える。このため、デバッグ対象実行ユニットの状態の如何にかかわらずデバッグ作業を行うことが可能となる。
【０１２０】
一方で、実行ユニットが備えるレジスタやキャッシュメモリなどの資源は、実行ユニットが使用するメモリ領域を参照するだけでは確認することができない。そして、レジスタの内容が参照できないことにより、必要なデバッグ情報が得られないことや、キャッシュメモリに最新の情報がとどまり続けることにより、メモリを参照するだけでは最新の情報が確認できないなどの弊害が生じる可能性がある。
【０１２１】
そのため、本実施形態の構成に加えて、デバッグ対象である実行ユニット上に、実行ユニットが備えるレジスタの内容の読み書きや、キャッシュメモリの内容の参照、制御などを行う実行ユニット内資源管理手段をデバッグ用プログラムにより構成するようにしてもよい。この実行ユニット内資源管理手段は、レジスタ内容読み出し・書込み手段と、キャッシュメモリ管理手段とから構成されている。
【０１２２】
レジスタ内容の読み出しを行う場合、対象とする実行ユニット上のデバッグ用プログラムに読み出し指示を与え、レジスタ内容読み出し・書込み手段により読み出しを行い、結果を通知する。書き込みを行う場合は、対象とする実行ユニット上のデバッグ用プログラムに書き込み指示と書き込むデータを与え、レジスタ内容読み出し・書込み手段により書き込みが行われるようにする。
【０１２３】
また、キャッシュメモリの内容の参照、制御を行うためのキャッシュメモリ管理手段は、キャッシュ内容吐き出し指示を受け取ると、実行ユニットにキャッシュメモリ吐き出し命令を実行するように制御を行う。キャッシュメモリの吐き出しが完了すると、メモリ上に最新の情報が書き込まれるので、その後、他の実行ユニット上の、記憶領域を参照することで情報を取得するデバッグ用プログラムで観測することも可能となる。もしくは、デバッグ対象実行ユニット上のデバッグ用プログラムにおいて、読み出したキャッシュメモリの内容を外部に通知するよう構成することも可能である。また、キャッシュメモリの動作モードの制御や、内容の更新などの制御も行うことができるよう構成することが望ましい。
【０１２４】
更に、デバッグ対象実行ユニット上でデバッグ用プログラムを実行中は、実行ユニットが備えるレジスタのうち、演算に用いるレジスタや、プログラムカウンタなどのプログラムの進行に関わるレジスタなどは、デバッグ対象プログラムの実行中に用いられていた内容が記憶領域のスタック領域に退避されている。しかし、そのスタック領域の内容がキャッシュメモリ上に残っており、記憶領域上には最新の値が保存されていない可能性がある。このため、前述のキャッシュメモリ管理手段を用いることによって、キャッシュメモリの内容を記憶領域上に吐き出すか、直接読み出すことにより、退避されたレジスタの内容を取得することで、デバッグ対象プログラムが実行中に保持していたレジスタ内容を取得するよう構成することができる。
【０１２５】
このような構成とすることにより、デバッグ対象実行ユニットでデバッグ用プログラムを使用可能である場合には、デバッグ対象実行ユニット上の、レジスタ内容読み出し・書込み手段及びキャッシュメモリ管理手段を備えるデバッグ用プログラムを利用することで、記憶領域を参照する方法で情報を取得するデバッグ用プログラムでは得られないレジスタ内容やキャッシュメモリの内容の読み書き、制御などが可能となる。
【０１２６】
（第６の実施形態）
次に、本発明の第６の実施形態のデバッグシステムについて図１３を参照して詳細に説明する。
【０１２７】
上記で説明した第１〜第５の実施形態では、実行ユニットに何らかの不具合が発生した場合には、外部の制御端末から起動指示を入力する必要があった。本発明の第６の実施形態では、実行ユニットに何等かの不具合が発生した場合には、外部の制御端末から起動指示を入力しない場合であっても、自動的に起動指示が生成されるようにしたものである。
【０１２８】
本発明の第６の実施形態のデバッグシステムは、図１に示した第１の実施形態のデバッグシステムにおける構成に加え、不具合の発生を検出する不具合検出手段６８、７８を備える。
【０１２９】
不具合検出手段６８、７８は、実行ユニットＡ、Ｂにおいて不具合が発生したことを検出すると、デバッグ用プログラム起動指示を生成する。
【０１３０】
ここで、不具合検出手段６８、７８によって不具合を検出したことを外部の制御端末に通知するようシステムを構成するのみでもよいが、更に、不具合発生を検出した時点で不具合が発生した実行ユニットやプログラム、不具合を発生させる原因となる実行ユニットやプログラム、もしくはその他の実行ユニットやプログラムも含めて、停止させる手段を備えるよう構成することが望ましい。
【０１３１】
なお、不具合検出手段６８、７８が設置される実行ユニットは、デバッグ用プログラム起動手段６２、７２が設置される実行ユニットと必ずしも一致している必要はなく、ある実行ユニットにどちらか片方のみが設置されていてもよい。
【０１３２】
本実施形態における全体の動作については、不具合検出手段６８、７８によって不具合を検出するステップが、デバッグ用プログラム起動指示を受信するステップの前に追加されることを除いて、上記で説明したいずれかの実施形態と同一である。
【０１３３】
次に、不具合検出手段６８、７８の構成・動作について詳細に説明する。
【０１３４】
不具合には、不具合の発生がシステムによって報告される実行時エラーと、報告が行われず、正常動作を妨げる不具合がある。実行時エラーには、不正メモリ参照、不正命令実行、ハードウェア例外などがある。正常動作を妨げる不具合には、無限ループなどによるストールや、暴走などがある。
【０１３５】
まず、実行時エラーを対象とした、不具合検出手段６８、７８の第１の構成について説明する。この場合の不具合検出手段は、システムにより報告される不具合を受信する不具合受信手段と、不具合発生を通知する通知手段を備える。ここで、実行時エラーが発生した場合に特定のプログラムが実行されるように構成されているシステムにおいては、この特定のプログラム内に不具合検出手段を構成してもよい。
【０１３６】
実行時エラーを対象とする場合で、実行ユニット上のプログラムとして不具合検出手段を構成した場合、実行時エラーが発生した実行ユニットの不具合検出手段によって不具合が検出される。この場合、デバッグ用プログラムを起動する実行ユニットを、不具合の発生した実行ユニットとして起動指示を生成することとしてもよいが、一方で実行時エラーが発生したものとの同一の実行ユニット上でデバッグ用プログラムを起動する場合、プログラムの起動が実行ユニットや記憶領域に与える影響により原因が判別できなくなる可能性もある。このような場合には、別の実行ユニットに対してデバッグ用プログラム起動指示を発行し、第５の実施形態におけるデバッグ用プログラムを起動するよう構成することが望ましい。
【０１３７】
次に、正常動作を妨げる不具合を対象とした不具合検出手段６８、７８の第２の構成について説明する。この場合の不具合検出手段は、デバッグ対象実行ユニット上で実行されるプログラムによって更新される情報を読み出す更新情報読出し手段と、情報の更新が正常に行われていることを確認する正常更新確認手段と、不具合発生を通知する通知手段によって構成される。
【０１３８】
次に、不具合検出手段６８、７８の第２の構成の動作について図１４を参照して説明する。ここでは、不具合発生通知手段を、不具合発生確認後にデバッグ用プログラム起動指示を生成するデバッグ用プログラム起動指示生成手段として構成した場合について例示する。
【０１３９】
まず、更新情報読出し手段が、他の実行ユニット上で実行されるプログラムによって更新される情報を読み出す（ステップＳ３０１）。この情報を元に、正常更新確認手段が、更新が正常に行われているかどうかを確認する（ステップＳ３０２）。更新が正常に行われている場合は（ステップＳ３０３、Ｙｅｓ）、次の更新を確認する。不具合の発生により更新に異常を検出すると（ステップＳ３０３、Ｎｏ）、デバッグ用プログラム起動指示生成手段がデバッグ用プログラム起動指示を生成し（ステップＳ３０４）、デバッグ用プログラム起動手段に起動指示を与える。なお、プログラムによって更新される情報は、情報を更新するプログラムを設けることで構成してもよいが、ＯＳが内部で使用する時刻情報をプログラムによって更新される情報として用いることで、別途プログラムを設けずに不具合検出手段を構成することができる。
【０１４０】
次に、正常動作を妨げる不具合を対象とした不具合検出手段６８、７８の第３の構成について説明する。この場合の不具合検出手段は、デバッグ対象実行ユニットに対して実行ユニット間割り込みを生成する割り込み生成手段と、デバッグ対象実行ユニットからの応答を確認する応答確認手段と、デバッグ用プログラム起動指示を生成する起動指示生成手段によって構成され、またデバッグ対象実行ユニットには割り込みに対する応答手段を備える。
【０１４１】
次に不具合検出手段の第３の構成の動作について図１５を参照して説明する。ここでは、不具合発生通知手段を、不具合発生確認後にデバッグ用プログラム起動指示を生成するデバッグ用プログラム起動指示生成手段として構成した場合について例示する。
【０１４２】
まず、信号送信手段が他の実行ユニットに対して信号を送信し（ステップＳ３１１）、応答が返ってくるのを待つ（ステップＳ３１２）。規定時間内に応答を受信した場合は（ステップＳ３１３、Ｙｅｓ）、正常であると判断し、次の信号を送信する。規定時間内に応答が返ってこない場合（ステップＳ３１３、Ｎｏ）、不具合により応答不能になったと判断し、起動指示生成手段がデバッグ用プログラム起動指示を生成し（ステップＳ３１４）、デバッグ用プログラム起動手段に起動指示を与える。なお、ここでは判断を規定時間内に応答が返ってくることとしたが、返ってきた応答が正常であるか、異常であるかを判断基準とすることもできる。
【０１４３】
次に、正常動作を妨げる不具合を対象とした不具合検出手段の第４の構成について説明する。この構成では、ストールが発生している実行ユニットを避けて、デバッグ用プログラムを起動可能な実行ユニットを選定するストール発生実行ユニット回避手段を構成する要素に、現在どの実行ユニットが選定されているかを検査する手段を追加することで構成される。
【０１４４】
次に、不具合検出手段６８、７８の第４の構成の動作について図１６を参照して説明する。ここでは、不具合発生通知手段を、不具合発生確認後にデバッグ用プログラム起動指示を生成するデバッグ用プログラム起動指示生成手段として構成した場合について例示する。
【０１４５】
不具合検出手段６８、７８の第４の構成では、図９におけるストール発生実行ユニット回避手段６６、７６の動作に加えて、図１６におけるステップＳ７８、ステップＳ７９の、ストール発生実行ユニット回避手段６６、７６の動作によって設定されている現在の実行ユニットがどれであるかを判定するステップが追加される。
【０１４６】
なお、図１６において、ステップＳ７１とステップＳ７４は意図的に選択するものではなく、その時点での状況によって必然的に選択される事項である。つまり、ステップＳ７１の分岐は、ステップＳ７２は実行ユニットＡによって実行される処理であるが、実行ユニットＡがストールしている場合はプログラムが実行されないため、この処理が行われずにステップＳ７３に進んでしまうことを示す。同様に、ステップＳ７４の分岐は、ステップＳ７５は実行ユニットＢによって実行される処理であるが、実行ユニットＢがストールしている場合はこの処理が行われずにステップＳ７６に進んでしまうことを示す。
【０１４７】
ここでは、デバッグ用プログラム起動指示の振り分け元となる起動ユニットの初期値が実行ユニットＢであるものとして説明する。まず、ステップＳ７１の段階で、実行ユニットＡがストールしていない場合（ステップＳ７１、Ｎｏ）、初期設定値は実行ユニットＢであるので（ステップＳ７８、Ｙｅｓ）、実行ユニットＡ上のプログラムが、デバッグ用プログラム起動指示の振り分け元となる起動ユニットの設定値を実行ユニットＡに変更する（ステップＳ７２）が、実行ユニットＡがストールしていた場合（ステップＳ７１、Ｙｅｓ）、ステップＳ７２の処理が行われずにステップＳ７３に進む。ここで起動指示がない場合（ステップＳ７３、Ｎｏ）、実行ユニットＢがストールしていなければ（ステップＳ７４、Ｎｏ）ステップＳ７９の検査に進む。ステップＳ７９では、起動指示の振り分け元となる実行ユニットの設定値を検査するが、この検査で、設定されている実行ユニットがＡであれば（ステップＳ７９、Ｙｅｓ）正常であるが、実行ユニットＡでない場合は（ステップＳ７９、Ｎｏ）ステップＳ７２が実行されなかったことになるため、実行ユニットＡの不具合を検出できる。この場合には、ステップＳ７７に進み、設定されている実行ユニット（この場合実行ユニットＢ）に起動指示が送信され、デバッグ用プログラムを起動する。ここで、実行ユニットＢがストールしていた場合には（ステップＳ７４、Ｙｅｓ）、同様にステップＳ７８にて不具合が検出され（ステップＳ７８、Ｎｏ）、デバッグ用プログラムが起動される。
【０１４８】
なお、不具合検出手段を構成するそれぞれの手法は互いに排他的なものではなく、任意の組み合わせで用いることも可能である。
【０１４９】
次に、本実施のデバッグシステムの効果について説明する。
【０１５０】
本実施形態では、不具合検出手段６８、７８を備え、不具合の発生を確認できるよう構成しているため、不具合発生の確認が困難なシステムであっても、不具合発生確認後にデバッグ用プログラムを起動してデバッグ作業を開始することができる。
【０１５１】
また、不具合発生を検出した時点で不具合が発生した実行ユニットやプログラム、不具合を発生させる原因となる実行ユニットやプログラム、もしくはその他の実行ユニットやプログラムも含めて、停止させる手段を備えるよう不具合検出手段を構成することで、不具合発生後に処理が進んでしまうことにより、不具合発生原因の確認が困難になる状況を避けることができる。
【０１５２】
また、不具合の発生を検出すると、デバッグ用プログラム起動指示を生成できるよう不具合検出手段を構成することで、作業者がデバッグ用プログラムを起動する実行ユニットやデバッグ用プログラムの種類を判断してデバッグ用プログラムを起動することなくデバッグ作業を開始することができる。
【０１５３】
（第７の実施形態）
次に、本発明の第７の実施形態のデバッグシステムについて図１７を参照して詳細に説明する。
【０１５４】
上記で説明した第５の実施形態のデバッグシステムによれば、ある実行ユニットがストールした場合でも、その実行ユニットに関するメモリの内容を読むことが可能となる。しかし、この第５の実施形態のデバッグシステムによっても、ストール状態となった実行ユニットのレジスタやキャッシュメモリの内容を読むことはできない。なぜならば、実行ユニットがストール状態となった場合には、一般的にレジスタやキャッシュメモリの内容の読み出しができなくなるからである。本発明の第７の実施形態のデバッグシステムは、このような場合であっても、ストールした実行ユニットのレジスタやキャッシュメモリの内容を読み出してデバッグを行うことを可能にするものである。
【０１５５】
本発明の第７の実施形態は、上記で説明した第１の実施形態における構成に加え、実行ユニットＡ用プログラム領域６内のデバッグ用プログラム６３には、実行ユニット間割り込み生成手段６３１と、応答受信手段６３２とを備えるようにし、デバッグ対象実行ユニットで実行される、割り込みハンドラ６９内に、情報取得・制御手段６９２、応答生成手段６９１を導入した構成となっている。
【０１５６】
実行ユニット間割り込み生成手段６３１は、デバッグ対象の実行ユニットＢに対して割り込みを発生させる。応答受信手段６３２は、デバッグ対象の実行ユニットＢにおける応答生成手段７９１からの応答を受信する。
【０１５７】
情報取得・制御手段６９２は、他の実行ユニットＢからの割り込みが発生した際に、レジスタ、キャッシュメモリ、フラッシュメモリ等の予め設定されたメモリ内の情報を取得する。応答生成手段６９１は、情報取得・制御手段６９２により得られた情報を、割り込みを発生させた実行ユニットＢに対して送信する。
【０１５８】
図２に示した第１の実施形態では、割り込みハンドラ６９は図示されていないが、割り込みハンドラは一般的な実行ユニットであれば標準的に備えられているプログラムである。
【０１５９】
また、本実施形態におけるデバッグシステムは、同様にして、実行ユニットＢ用プログラム領域７内のデバッグ用プログラム７３には、実行ユニット間割り込み生成手段７３１と、応答受信手段７３２とを備えるようにし、デバッグ対象実行ユニットで実行される、割り込みハンドラ７９内に、情報取得・制御手段７９２、応答生成手段７９１を導入した構成となっている。
【０１６０】
尚、本実施形態では、第１の実施形態の構成に対して適用した場合を説明しているが、第２〜第６の実施形態に対しても同様に適用することができるものである。
【０１６１】
次に、図１８のフローチャートを参照して本実施形態の動作について詳細に説明する。
【０１６２】
ここでは、実行ユニットＡのデバッグ用プログラム６３から、実行ユニットＢ側のデバッグを行う場合について例示する。まず、デバッグ用プログラム６３は、対象となる実行ユニットＢに対して実行ユニット間割り込みを発行する（ステップＳ４０１）。すると実行ユニットＢの割り込みハンドラ７９が起動する（ステップＳ４０２）が、この割り込みハンドラ７９においてデバッグ情報取得・制御手段７９２を用いることにより、実行ユニットＢのレジスタ内容の収集や書込み、キャッシュ内容の参照やフラッシュメモリなどの、情報収集や制御などを行う（ステップＳ４０３）。その後、応答生成手段７９１によって実行ユニットＡに対して応答を生成し（ステップＳ４０４）、実行ユニットＡは応答受信手段６３２を用いてこれを受信する（ステップＳ４０５）。ここで、作業内容が制御のみの場合は応答には制御の成否情報のみを含むこととすればよいが、情報を参照する作業の場合は収集した情報を応答に含むように構成する。
【０１６３】
もしくは、実行ユニットＢ側で周期的に発生するタイマ割り込みの割り込みハンドラとして割り込みハンドラ７９を構成し、対象プロセスの実行制御を行う指示を実行ユニットＡから実行ユニットＢへの通信手段を用いることで与えるよう構成してもよい。ただし、この場合は実行制御を行うタイミングが、周期的に発生する割り込みのタイミングのみになるという制約が生じる。
【０１６４】
また、実行ユニットＢのデバッグ用プログラム７３から、実行ユニットＡ側のデバッグを行う場合についても同様の仕組みで実現可能である。
【０１６５】
更に、本実施形態では２個の実行ユニットを備えるシステムについて記載しているが、３個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【０１６６】
次に、本実施形態のデバッグシステムの効果について説明する。
【０１６７】
本実施形態では、デバッグ用プログラム６３、７３には実行ユニット間割り込み生成手段６３１、７３１、応答受信手段６３２、７３２を備え、デバッグ対象実行ユニットで実行される割り込みハンドラ内に、情報取得・制御手段、応答手段を備える。そして、デバッグ対象実行ユニット以外の実行ユニット上で動作しているデバッグ用プログラムから、デバッグ対象実行ユニットに割り込みを発生させ、割り込みハンドラ内で情報の取得や、制御を行う。
【０１６８】
上述したように、割り込みハンドラとは、割り込みが発生した場合に、その割り込みを処理するために最初に起動されるプログラムである。そのため、実行ユニットＡ、Ｂの割り込みハンドラ６９、７９内に、情報取得・制御手段６９２、７９２および応答生成手段６９１、７９１をそれぞれ設けることにより、実行ユニットＡ、Ｂがストール状態となった場合でもストール状態となった実行ユニットのキャッシュメモリやレジスタの内容を読むことが可能となる。
【０１６９】
（第８の実施形態）
次に、本発明の第８の実施形態のデバッグシステムについて図１９を参照して詳細に説明する。
【０１７０】
上記で説明した第１〜第７の実施形態では、ある実行ユニットがストール状態となった場合に、その実行ユニットのデバッグを行うものであった。本実施形態では、ストール状態となった実行ユニットを正常状態に復帰させるための構成について説明する。
【０１７１】
実行ユニットがストール状態となる場合、通常動作プログラムにより実行されているあるプロセスが暴走していることが考えられる。このようにあるプロセスが暴走状態になると、他のプロセスは不具合がないにもかかわらず実行ユニット全体としてはストール状態になり機能しなくなってしまう。そこで、本発明の第８の実施形態のデバッグシステムでは、あるプロセスが暴走した場合でも、暴走したプロセスを停止させ、不具合の修正を行うことにより正常状態に復帰させることができるようにする。
【０１７２】
本発明の第８の実施形態のデバッグシステムの構成を図１９に示すが、ここでは実行ユニットＢがデバッグ対象実行ユニットとなり、実行ユニットＡから実行ユニットＢに対するデバッグを行う場合の構成のみを示す。任意の実行ユニットから任意の実行ユニットをデバッグする場合には、同様の構成を各実行ユニットに設ける必要がある。
【０１７３】
本実施形態のデバッグシステムは、図１９に示されるように、図２に示した第１の実施形態のデバッグシステムにおける構成において、デバッグ用プログラム６３には実行ユニット間割り込み生成手段（図１９中では、割り込み生成手段と表示する。）６３１と、応答受信手段６３２とを備えるようにし、デバッグ対象実行ユニットである実行ユニットＢにおいて実行される割り込みハンドラ７９内には、プロセス制御手段７９３と、応答生成手段７９１を導入する。
【０１７４】
実行ユニット間割り込み生成手段６３１は、デバッグ対象実行ユニットに対する割り込みを発生させる。応答受信手段６３２は、デバッグ対象の実行ユニットＢにおける応答生成手段７９１からの応答を受信する。
【０１７５】
プロセス制御手段７９３は、デバッグ対象の実行ユニットにおいて起動している通常動作プログラム７４のプロセス制御を行って暴走しているプロセスを停止させる。応答生成手段６９１は、プロセス制御手段７９３によるプロセス制御の結果得られた情報を、割り込みを発生させた実行ユニットＡに対して送信する。
【０１７６】
次に、図２０のフローチャートを参照して本実施形態の動作について詳細に説明する。ここでは、実行ユニットＡのデバッグ用プログラムから、実行ユニットＢ側のプロセス制御を行う場合について例示する。まず、デバッグ用プログラムは、対象となる実行ユニットに対して実行ユニット間割り込みを発行する（ステップＳ４０１）。すると実行ユニットＢの割り込みハンドラ７９が起動する（ステップＳ４０２）が、この割り込みハンドラ７９においてプロセス制御手段７９３を用いることにより、実行ユニットＢで実行されている通常動作プログラム７４のプロセス制御を行う（ステップＳ４０６）。その後、応答生成手段７９１によって実行ユニットＡに対して応答を生成し（ステップＳ４０４）、実行ユニットＡは応答受信手段６３２を用いてこれを受信する（ステップＳ４０５）。
【０１７７】
もしくは、実行ユニットＢ側で周期的に発生するタイマ割り込みの割り込みハンドラとして割り込みハンドラ７９を構成し、対象プロセスの実行制御を行う指示を実行ユニットＡから実行ユニットＢへの通信手段を用いることで与えるよう構成してもよい。ただし、この場合は実行制御を行うタイミングが、周期的に発生する割り込みのタイミングのみになるという制約が生じる。
【０１７８】
具体的なプロセス制御の実現には、次のような方法がある。
【０１７９】
第１のプロセス制御としては、ＯＳのスケジューラに、スケジューラが行うプロセス制御を外部からの指示に基づいて変更するプロセス制御変更手段を備えるようにし、割り込みハンドラ７９内のプロセス制御手段７９３から、プロセス変更指示をプロセス制御変更手段に送信することで実現することができる。
【０１８０】
第２のプロセス制御としては、割り込みハンドラ７９内のプロセス制御手段７９３から、ＯＳのＡＰＩ（Application Program Interface)（システムコールなど）に類似する手順により、制御対象プロセスに対してプロセス制御シグナルを発行するプロセス制御シグナル発行手段を備え、対象プロセスにプロセス制御シグナルを発行することで実現することができる。
【０１８１】
第３のプロセス制御としては、割り込みハンドラ７９内から、記憶領域上に退避されている制御対象プロセスへの戻りアドレスを、別のアドレスに変更する手段を備え、戻りアドレスを不正なアドレスに変更し、不正アドレス参照例外を発生させることで実現することができる。ここで、例外を発生させる処理のみでも例外による異常終了処理をＯＳが行うため、プロセスを終了させることができるが、例外ハンドラ内に、プロセスを停止させるなどの、異常終了処理以外の制御を行うよう構成することで、様々なプロセス制御を行うことが可能となる。
【０１８２】
第４のプロセス制御としては、割り込みハンドラ７９内から、記憶領域上に退避されている制御対象プロセスへの戻りアドレスに存在する命令を、別の命令に変更する手段を備え、戻りアドレスに存在する命令をデバッグ命令、不正な命令などに置き換え、例外を発生させることで実現することができる。ここで、例外を発生させる処理のみでも例外による異常終了処理をＯＳが行うため、プロセスを終了させることができるが、例外ハンドラ内に、プロセスを停止させるなどの、異常終了処理以外の制御を行うよう構成することで、様々なプロセス制御を行うことが可能となる。
【０１８３】
ユーザプロセスとして構成されるデバッグ用プログラムからプロセス制御用システムコールを発行し、プロセス制御を行う既存手法を用いる場合、実行ユニットで実行されているプロセスのいずれかが暴走した場合にはデバッグ用プログラムに制御が移らず、結果としてプロセス制御を行うことができない弊害がある。しかし、割り込みハンドラ内からプロセス制御を行う上記いずれかのプロセス制御手段を用いる場合、割り込みハンドラはユーザプロセスに比べて高い優先度で実行されるため、暴走したプロセスが存在する場合であってもプロセス制御を行うことが可能となる。
【０１８４】
また、実行ユニットＢのデバッグ用プログラムから、実行ユニットＡ側のデバッグを行う場合についても同様の仕組みで実現可能である。
【０１８５】
更に、本実施形態では２個の実行ユニットを備えるシステムについて記載しているが、３個以上の任意の個数の実行ユニットを備えるシステムについても容易に拡張可能である。
【０１８６】
次に、本実施形態のデバッグシステムの効果について説明する。
【０１８７】
本実施形態では、デバッグ対象実行ユニットによって実行される割り込みハンドラ内に、プロセス制御手段を導入し、割り込みハンドラ内からデバッグ対象プロセスの制御を行うよう構成する。そして、デバッグ対象実行ユニット以外の実行ユニット上で動作しているデバッグ用プログラムから、デバッグ対象実行ユニットに割り込みを発生させ、割り込みハンドラ内でプロセス制御を行うことにより、デバッグ対象実行ユニット以外の実行ユニットからプロセス制御を行うことが可能になる。また、ユーザプロセスよりも高い優先度で実行される割り込みハンドラ内からプロセス制御を行うため、暴走したプロセスが存在する場合であっても、暴走しているプロセスを停止させ、不具合が発生している状況を解析して変数内容の修正等の処理を行い、更に再度プログラムを実行させて不具合が解消されたか否かを観察することが可能となる。そして、このような処理を繰り返すことにより最終的にはストール状態となっていた実行ユニットを正常動作に復帰することが可能となる。
【産業上の利用可能性】
【０１８８】
本発明は、複数の実行ユニットを備えるシステムＬＳＩのデバッグシステムといった用途に適用できる。また、複数の実行ユニットを備える組み込みシステム、複数の実行ユニットを備えるコンピュータシステム用のデバッグシステムといった用途にも適用可能である。
【図面の簡単な説明】
【０１８９】
【図１】本発明の第１の発明を実施するための対象ハードウェアの構成を示すブロック図である。
【図２】本発明の第１の実施形態のデバッグシステムの構成を示すブロック図である。
【図３】デバッグ用プログラム起動指示振り分け手段６１、７１の構成を示すブロック図である。
【図４】本発明の第１の実施形態のデバッグシステムの動作を示すフローチャートである。
【図５】デバッグ用プログラム起動指示振り分け手段６１の動作を示すフローチャートである。
【図６】本発明の第２の実施形態のデバッグシステムの構成を示すブロック図である。
【図７】本発明の第３の実施形態のデバッグシステムの構成を示すブロック図である。
【図８】本発明の第４の実施形態のデバッグシステムの構成を示すブロック図である。
【図９】ストール発生実行ユニット回避手段６６の動作を示すフローチャートである。
【図１０】本発明の第５の実施形態のデバッグシステムの構成を示すブロック図である。
【図１１】第２の物理・仮想アドレス変換手段６７１の動作を示すフローチャートである。
【図１２】情報抽出手段６７２の動作を示すフローチャートである。
【図１３】本発明の第６の実施形態のデバッグシステムの構成を示すブロック図である。
【図１４】不具合検出６８、７８の第２の構成の動作を示すフローチャートである。
【図１５】不具合検出６８、７８の第３の構成の動作を示すフローチャートである。
【図１６】不具合検出６８、７８の第４の構成の動作を示すフローチャートである。
【図１７】本発明の第７の実施形態のデバッグシステムの構成を示すブロック図である。
【図１８】本発明の第７の実施形態の動作を示すフローチャートである。
【図１９】本発明の第８の実施形態の構成を示すブロック図である。
【図２０】本発明の第８の実施形態の動作を示すフローチャートである。
【図２１】従来のデバッグシステムの構成を示すブロック図である。
【図２２】従来の他のデバッグシステムの構成を示すブロック図である。
【図２３】図２２に示した従来のデバッグシステムの動作を示すフローチャートである。
【符号の説明】
【０１９０】
１    通信ポート
２    記憶手段
３  プログラム格納手段
４    実行ユニットＡ
５    実行ユニットＢ
６    実行ユニットＡ用プログラム領域
７    実行ユニットＢ用プログラム領域
８    実行ユニットＣ用プログラム領域
６１、７１、８１    デバッグ用プログラム起動指示振り分け手段
６２、７２、８２    デバッグ用プログラム起動手段
６３、７３、８３    デバッグ用プログラム
６４、７４、８４    通常動作プログラム
６５、７５、８５    中継手段
６６、７６    ストール発生実行ユニット回避手段
６７、７７    デバッグ用プログラム
６８、７８    不具合検出手段
６９、７９    割り込みハンドラ
６１１、７１１    通信ポートからの受信手段
６１２、７１２    実行ユニット間通信の送信手段
６１３、７１３    通信ポートの通信対象変更手段
６１４、７１４    デバッグ用プログラム起動手段への指示送信手段
６１５、７１５    実行ユニット間通信の受信手段
６３１、７３１    実行ユニット間割り込み生成手段
６３２、７３２    応答受信手段
６７１、７７１    物理・仮想アドレス変換手段
６７２、７７２    情報抽出手段
６９１、７９１    応答生成手段
６９２、７９２    情報取得・制御手段
７９３    プロセス制御手段
８０１    演算プロセッサ群
８０２    メモリ装置
８０３    診断プロセッサ
８２１    演算プロセッサの内部情報
８３１    ストール検出手段
８３２    採集手段
８３３    演算プロセッサの内部状態一時保持手段
８３４    書込み手段
８３５    書込み報告手段
８３６    初期化手段
９０１    ＣＰＵ−Ａ
９０２    ＣＰＵ−Ｂ
９０３    ＣＰＵ制御回路
９０４    割り込み制御回路
９０５    バスとレース機能
９０６    ストラップ取込み回路
９０７    デバッグ制御回路
９０８    ストラップ設定手段
Ａ、Ｂ    実行ユニット
【図１】
0004787551.tif 000002
【図２】
0004787551.tif 000003
【図３】
0004787551.tif 000004
【図４】
0004787551.tif 000005
【図５】
0004787551.tif 000006
【図６】
0004787551.tif 000007
【図７】
0004787551.tif 000008
【図８】
0004787551.tif 000009
【図９】
0004787551.tif 000010
【図１０】
0004787551.tif 000011
【図１１】
0004787551.tif 000012
【図１２】
0004787551.tif 000013
【図１３】
0004787551.tif 000014
【図１４】
0004787551.tif 000015
【図１５】
0004787551.tif 000016
【図１６】
0004787551.tif 000017
【図１７】
0004787551.tif 000018
【図１８】
0004787551.tif 000019
【図１９】
0004787551.tif 000020
【図２０】
0004787551.tif 000021
【図２１】
0004787551.tif 000022
【図２２】
0004787551.tif 000023
【図２３】
0004787551.tif 000024