JPWO2006137223A1 - デバッグシステム、デバッグ方法、およびプログラム - Google Patents

Abstract

デバッグ用プログラム起動指示振り分け部（６１，７１）は、通信ポート（１）から送られてくるデバッグ用プログラムの起動指示を受信すると、この起動指示により指定されている実行ユニットに対して受信したデバッグ用プログラムを振り分ける。デバッグ用プログラム起動部（６２，７２）は、実行ユニット（Ａ，Ｂ）毎に設けられ、起動指示振り分け部（６１，７１）により振り分けられた起動指示に基づいて、この起動指示により指定された実行ユニット上でデバッグ用プログラム（６３，７３）を起動する。

Description

本発明は、デバッグシステム、デバッグ方法、およびプログラムに関し、特に、複数の実行ユニットを有するシステムにおけるデバッグシステム、デバッグ方法およびプログラムに関する。

近年、開発するプログラムの規模は増大してきており、デバッグ作業に要する時間が製品開発スケジュールに与える影響が大きくなってきている。そのため、効率よくデバッグを行うことができる環境の構築が望まれている。効率よくデバッグを行うための手法として、特許文献１の「プロセッサ情報収集装置およびそのプログラム記録媒体」に記載されたデバッグシステムのように、デバッグを支援する診断プロセッサを用いる方法がある。

図１に示すように、この従来のデバッグシステムは、演算プロセッサ群８０１と、メモリ装置８０２と、演算プロセッサ群８０１の動作状態を監視する診断プロセッサ８０３とを備えている。そして、診断プロセッサ８０３は、演算プロセッサ群８０１を構成する各演算プロセッサがストール状態になったことを検出するストール検出部８３１と、演算プロセッサの内部状態を採集する採集部８３２と、演算プロセッサの内部状態をメモリ装置８０２に保存する書込み部８３４と、メモリ装置８０２に演算プロセッサの内部状態を保持したまま情報処理システムを初期化する初期化部８３６とから構成されている。

このような構成を有する従来のデバッグシステムは次のように動作する。

まず、ストール検出部８３１が、演算プロセッサ群８０１を構成する各演算プロセッサがストール状態になったことを検出する。ストールが発生した場合、採集部８３２が、演算プロセッサの内部状態を採集し、書込み部８３４が、採集された演算プロセッサの内部状態を、演算プロセッサの内部状態８２１としてメモリ装置８０２に書き込む。そして、メモリ装置８０２に演算プロセッサの内部状態を保持したまま情報処理システムが初期化される。よって、初期化後もメモリ装置８０２上に演算プロセッサの内部状態の情報が保存されているため、この情報を用いることで、ストールが発生した状況についてのデバッグ作業を行うことができる。

しかし、特許文献１に記載の従来技術のように、診断プロセッサ８０３というデバッグのための高機能な専用ハードウェアをシステムに搭載する手法は、デバッグを効率化する効果をもたらすものの、通常動作に寄与しないハードウェアの追加が必要となり、システムのコストが増加するという弊害がある。また、特に組込み機器ではコストに対する要求が厳しく、専用ハードウェアの搭載が許容されないことが多い。

一方で、半導体集積回路の微細化や、システムＬＳＩに対して要求される機能の高度化に伴い、システムＬＳＩにＣＰＵなどの複数の実行ユニットを搭載することが増えてきている。デバッグのための専用ハードウェアによるコストの増加を避けつつ、デバッグを効率化する従来技術として、特許文献２の「マルチＣＰＵのリセット回路およびリセット方法」に記載されたデバッグシステムがある。

図２に示すように、この従来のデバッグシステムは、複数のＣＰＵ（ＣＰＵ−Ａ９０１、ＣＰＵ−Ｂ９０２）を内蔵するシステムＬＳＩのリセットおよび割り込みを制御するＣＰＵ制御回路９０３を備えている。ＣＰＵ制御回路９０３は、複数のＣＰＵ（ＣＰＵ−Ａ９０１、ＣＰＵ−Ｂ９０２）のうちの１つを、通常動作用プログラムをデバッグ用プログラムに置き換えたデバッグ手段に設定する機能を有する。また、ＣＰＵ制御回路９０３は、割込み制御回路９０４と、バストレース機能９０５と、ストラップ取込み回路９０６と、デバッグ制御回路９０７とを備えている。

このような構成を有する従来のデバッグシステムの動作について、図３を参照して説明する。

まず、ＣＰＵ制御回路９０３がハードウェアリセットを検知すると、デバッグ制御回路９０７が、内部の各機能ブロック（図示せず）にリセットを発行する（ステップＳ９１）。

次に、ストラップ取込み回路９０６が、ストラップ設定部９０８からのストラップ情報等の外部設定情報を読み込む（ステップＳ９２）。

読み込んだストラップ情報が通常動作を示している場合（ステップＳ９３のＮｏ）、デバッグ制御回路９０７が、読み込んだストラップ情報に基づき、ＣＰＵ−Ａ９０１およびＣＰＵ−Ｂ９０２と各機能ブロックとに対するリセットを解除する（ステップＳ９４）。

リセットが解除されると、各機能ブロックは動作を開始する（ステップＳ９５）。

一方、読み込んだストラップ情報がデバッグを指定している場合（ステップＳ９３のＹｅｓ）、デバッグ処理に入る（ステップＳ９６）。

ここで、ストラップ情報がデバッガとしてＣＰＵ−Ｂ９０２を選択している場合（ステップＳ９６１のＢ）、デバッグ制御回路９０７が、ストラップ情報により選択されたＣＰＵ−Ｂ９０２のリセットを解除する（ステップＳ９６２）。

その後、デバッガＣＰＵ−Ｂ９０２が起動し（ステップＳ９６３）、立ち上がり動作が完了すると（ステップＳ９６４のＹｅｓ）、ターゲット側のＣＰＵ−Ａ９０１と各機能ブロックのリセットを解除する（ステップＳ９６５）。

一方、ストラップ情報がデバッガとしてＣＰＵ−Ａ９０１を選択している場合（ステップＳ９６１のＡ）、デバッグ制御回路９０７が、ストラップ情報により選択されたＣＰＵ−Ａ９０１のリセットを解除する（ステップＳ９６６）。

その後、デバッガＣＰＵ−Ａ９０１が起動し（ステップＳ９６７）、立ち上がり動作が完了すると（ステップＳ９６８のＹｅｓ）、ターゲット側のＣＰＵ−Ｂ９０２と各機能ブロックのリセットを解除する（ステップＳ９６９）。

複数の実行ユニットが連携動作するシステムにおいて実行されるプログラムのデバッグを行う場合、複数の実行ユニット間の通信に関する情報であって実行ユニット以外の外部から確認できる情報や、不具合発生時の情報を保存しておいて、これらの情報を後から確認することがある。しかし、この方法では、不具合発生原因を十分に追究することができないことが多い。他方、通常動作プログラムにより生成される送信内容を擬似的に生成するデバッグ用プログラムや、送受信内容をデバッグ作業者に通知するデバッグ用プログラムを利用すると、不具合発生原因を効果的に追求できることが多い。そのため、これらのデバッグ用プログラムを実行ユニット上で動作させてデバッグ作業を行うことがある。

一方で、これらのデバッグ用プログラムを事前に動作させておくと、ＣＰＵの負荷が高くなり、また、デバッグ用プログラムが記憶領域を使用することから、通常動作プログラムの動作タイミングなどに影響が出る。そのため、デバッグ用プログラムの存在によって、通常動作で発生する可能性がある不具合が発生しない、また、この逆に通常動作プログラムのみの実行では発生しないはずの不具合が発生するなどの弊害がある。

また、複数の実行ユニットが連携動作するシステムにおいて実行されるプログラムにおいては、特にタイミングに起因する不具合については、その不具合がどの実行ユニットで発生するかが一意に定まらないため、その不具合の発生を想定することは困難である。ここで、実行ユニットがストール状態になった場合や、実行ユニットの動作に影響が出る不具合が発生した場合、ストール状態になった実行ユニット上のデバッグ用プログラムや、動作に影響を受けた実行ユニット上のデバッグ用プログラムが使用できないことがある。そのため、別の実行ユニット上でデバッグ用プログラムを動作させる必要がある。しかし、不具合発生箇所が一意に定まらない不具合の場合、その不具合に影響を受けない実行ユニットを決定しておくことができない。

また、特許文献２に記載の従来手法は、リセット時にデバッグ用プログラムを起動する実行ユニット（デバッグ用ＣＰＵ）を割り当てることを特徴としており、デバッグ用ＣＰＵを変更する場合には再度リセットを行う必要がある。そのため、リセット時に割り当てられたデバッグ用ＣＰＵの動作に影響を与える不具合が発生した場合、その状況をデバッグすることができない。

上述したように、上記の従来のデバッグシステムでは、複数の実行ユニット（ＣＰＵ）が連携動作するシステムにおいてデバッグを行う際に、下記のような問題が発生する。
（１）予めデバッグ用プログラムを起動させておくと、通常動作プログラムのみを動作させた場合と動作タイミングが異なってしまうため、デバッグ用プログラムの存在によって、通常動作で発生する可能性がある不具合が発生しない、また、この逆に通常動作プログラムのみの実行では発生しないはずの不具合が発生する。
（２）デバッグ用プログラムを実行させる実行ユニットを予め設定しておく必要があるが、設定された実行ユニットの動作に影響を及ぼす不具合が発生した場合、その状況をデバッグすることができなくなる。
特開平１１−１８４７３６号公報 特開２００４−１６４１１３号公報

本発明は上記の問題点に鑑みてなされたものであって、複数の実行ユニットが連携動作するシステムにおいて、任意の実行ユニット上で任意のタイミングでデバッグ用プログラムを起動して、デバッグ作業を行うことを可能にするデバッグシステム、デバッグ方法、およびプログラムを提供することを目的とする。

上記目的を達成するために、本発明のデバッグシステムは、
複数の実行ユニットが連携動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグシステムであって、
デバッグ用プログラムの起動を指示する起動指示を受信すると、前記複数の実行ユニットに対して前記起動指示を振り分ける起動指示振り分け手段と、
前記複数の実行ユニットの各々に対応して設けられ、前記起動指示振り分け手段により振り分けられた起動指示に基づいて、対応する実行ユニット上でデバッグ用プログラムを起動する複数のデバッグ用プログラム起動手段とを備えている。

また、前記起動指示振り分け手段は、前記起動指示により指定された実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信してもよい。

本発明によれば、デバッグ用プログラムを起動するためのデバッグ用プログラム起動手段を各実行ユニット毎に設け、このデバッグ用プログラム起動手段により、起動指示振り分け手段により振り分けられた起動指示に基づいてデバッグ用プログラムの起動を行うようにしている。そのため、通常動作プログラムのみを動作させた状態で不具合が確認された場合であっても、任意のタイミングで不具合の発生原因となる処理を行っている実行ユニット上でデバッグ用プログラムを起動してデバッグ作業を行うことが可能となる。

また、前記起動指示振り分け手段は、前記複数の実行ユニットの各々の動作状況に基づいて定められる実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信してもよい。

また、前記起動指示振り分け手段は、前記複数の実行ユニットの各々が利用する記憶領域の空き容量を検出し、検出された空き容量に余裕のある実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信してもよい。

このようにすれば、空き容量不足でデバッグ用プログラムを起動できない状態が発生することを防ぐことが可能となる。

また、前記起動指示振り分け手段は、デバッグ対象の実行ユニットと関係が無いまたは関係が少ない実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信してもよい。

このようにすれば、不具合の発生原因となる処理を行っている実行ユニットと連携して動作している実行ユニット上でデバッグ用プログラムを起動して不具合の発生原因が確認できなくなるという弊害の発生を防ぐことが可能となる。

また、本発明の他のデバッグシステムでは、前記複数の実行ユニットのいずれか１つに対応して設けられ、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する中継手段をさらに備える。

本発明によれば、通信ポートの通信対象の実行ユニットが固定されているようなシステムに対しても適用が可能になる。

さらに、本発明の他のデバッグシステムでは、前記複数の実行ユニットの各々に対応して設けられ、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する複数の中継手段をさらに備える。

本発明によれば、デバッグ用プログラムに対して送信されるコマンドを中継する中継手段が各実行ユニット毎に設けられているので、ある実行ユニットがストール状態となった場合でも、通信ポートの通信対象の実行ユニットの煩雑な切り替えを不要としつつ、複数の実行ユニットで同時に複数のデバッグ用プログラムを起動することが可能となる。

さらに、本発明の他のデバッグシステムでは、前記起動指示がストール状態の実行ユニットに対応するデバッグ用プログラム起動手段には送信されないようにするストール発生実行ユニット回避手段をさらに備える。

本発明によれば、ストール発生実行ユニット回避手段を設けることにより、デバッグ用プログラム起動指示がストール状態の実行ユニットに対応するデバッグ用プログラム起動手段に対して送信されてしまい、デバッグ作業を行うことができないという弊害を防ぐことが可能となる。

さらに、本発明の他のデバッグシステムでは、
前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内には、
仮想アドレスを物理アドレスに変換する物理・仮想アドレス変換手段と、
前記物理・仮想アドレス変換手段により変換された物理アドレスを用いて、オペレーティングシステムが管理情報をメモリに配置する構造を考慮して、前記デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象の実行ユニットが利用する記憶領域から必要情報を抽出する情報抽出手段とが構成されている。

本発明によれば、デバッグ用プログラム内に物理・仮想アドレス変換手段と情報抽出手段とを構成しているので、デバッグ用プログラムは、起動された実行ユニットとは異なる実行ユニットが利用する記憶領域を参照することが可能になる。そのため、デバッグ対象の実行ユニットがストール状態となった場合でも、外部から記憶領域の内容を確認することが可能となる。

さらに、本発明の他のデバッグシステムでは、前記複数の実行ユニットの中から不具合が発生した実行ユニットを検出し、検出された実行ユニットのデバッグを行うための起動指示を生成する不具合検出手段をさらに備える。

本発明によれば、複数の実行ユニットの中のいずれかの実行ユニットに不具合が発生した場合、その不具合をデバッグするためのデバッグ用プログラムの起動指示を不具合検出手段により生成してデバッグ用プログラムを自動的に起動することが可能となる。従って、外部からデバッグ用プログラム起動指示を生成することなく、デバッグ作業を行うことが可能となる。

さらに、本発明の他のデバッグシステムでは、
前記複数の実行ユニットの各々において割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラ内には、
他の実行ユニットからの割り込みが発生した際に、予め設定されたメモリ内の情報を取得する情報取得・制御手段と、
前記情報取得・制御手段により取得された情報を、割り込みを発生させた実行ユニットに対して送信する応答生成手段とが構成されており、
前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内には、
デバッグ対象の実行ユニットに対して割り込みを発生させる実行ユニット間割り込み生成手段と、
デバッグ対象の実行ユニットからの応答を受信する応答受信手段とが構成されている。

本発明によれば、割り込みハンドラ内にメモリ内の情報を取得するための情報取得・制御手段を構成し、デバッグ用プログラム内に実行ユニット間割り込み生成手段を構成しているので、デバッグ対象の実行ユニットがストール状態となった場合でも、キャッシュメモリやレジスタ等のメモリ内の情報を取得してデバッグ作業を行うことが可能となる。

以上説明したように、本発明は、デバッグ用プログラム起動指示振り分け手段と、デバッグ用プログラム起動手段を備えることにより、任意のタイミングで任意の実行ユニット上にデバッグ用プログラムを起動できるよう構成されていることにより、通常動作プログラムのみを実行した状態で不具合を発生させるか、その直前まで進め、その後、不具合の発生原因となる処理を行っている実行ユニット上にデバッグ用プログラムを起動し、デバッグ作業を行うことが可能になるという効果を得ることができる。

従来のデバッグシステムの一構成例を示すブロック図である。 従来のデバッグシステムの他の構成例を示すブロック図である。 図２に示したデバッグシステムの動作を説明するフローチャートである。 本発明を実施するための対象ハードウェアの一構成例を示すブロック図である。 本発明の第１の実施形態のデバッグシステムの構成を示すブロック図である。 図５に示したデバッグ用プログラム起動指示振り分け部の一構成例を示すブロック図である。 図５に示したデバッグシステムの動作を説明するフローチャートである。 図５および図６に示したデバッグ用プログラム起動指示振り分け部の動作を説明するフローチャートである。 本発明の第２の実施形態のデバッグシステムの構成を示すブロック図である。 本発明の第３の実施形態のデバッグシステムの構成を示すブロック図である。 本発明の第４の実施形態のデバッグシステムの構成を示すブロック図である。 図１１に示したストール発生実行ユニット回避部の動作を説明するフローチャートである。 本発明の第５の実施形態のデバッグシステムの構成を示すブロック図である。 図１３に示した物理・仮想アドレス変換部の第２の物理・仮想アドレス変換動作を説明するフローチャートである。 図１３に示した情報抽出部の動作を説明するフローチャートである。 本発明の第６の実施形態のデバッグシステムの構成を示すブロック図である。 図１６に示した不具合検出部の第２の構成の動作を説明するフローチャートである。 図１６に示した不具合検出部の第３の構成の動作を説明するフローチャートである。 図１６に示した不具合検出部の第４の構成の動作を説明するフローチャートである。 本発明の第７の実施形態のデバッグシステムの構成を示すブロック図である。 図２０に示したデバッグシステムの動作を説明するフローチャートである。 本発明の第８の実施形態のデバッグシステムの構成を示すブロック図である。 図２２に示したデバッグシステムの動作を説明するフローチャートである。

以下に、本発明の実施形態について図面を参照して説明する。

（第１の実施形態）
まず、本発明の第１の実施形態のデバッグシステムについて図面を参照して説明する。

図４に示すように、本実施形態のデバッグシステムは、２個の実行ユニットＡ，Ｂと、通信ポート１と、ＲＡＭ（Random Access Memory）等により構成され書き換え可能な記憶部２と、ＨＤＤ（Hard Disk Drive）装置等により構成され各種プログラムが格納されたプログラム格納部３とを備えている。そして、記憶部２の記憶領域は、実行ユニットＡ用プログラム領域６と、実行ユニットＢ用プログラム領域７とから構成されている。

図５に示すように、実行ユニットＡ用プログラム領域６は、デバッグ用プログラム起動指示振り分け部（図５中では、振り分け部と表示する。）６１と、デバッグ用プログラム起動部（図５中では、起動部と表示する。）６２と、デバッグ用プログラム６３と、通常動作プログラム６４とを備えている。これらは実行ユニットＡ上で実行されるプログラムとして構成されている。

また、図５に示すように、実行ユニットＢ用プログラム領域７も、デバッグ用プログラム起動指示振り分け部７１と、デバッグ用プログラム起動部７２と、デバッグ用プログラム７３と、通常動作プログラム７４とを備えている。これらは実行ユニットＢ上で実行されるプログラムとして構成されている。

ここで、デバッグ用プログラム起動指示振り分け部６１，７１およびデバッグ用プログラム起動部６２，７２は、記憶部２内では単にプログラムとして記憶されていて、実行ユニットＡ，Ｂ上で起動されて初めて各種の動作を行うものである。ただし、ここでは、説明を簡単にするために、デバッグ用プログラム起動指示振り分け部６１，７１およびデバッグ用プログラム起動部６２，７２は、独自に各種の動作を行うものとして説明する。

これらの各種プログラムは、プログラム格納部３から記憶部２に読み込まれ、記憶部２上の所定の領域に記憶される。

デバッグ用プログラム起動指示振り分け部６１，７１は、通信ポート１から送られてくるデバッグ用プログラムの起動指示（以下、単に、起動指示と称する。）を受信すると、この起動指示により指定されている実行ユニットに対して、受信したデバッグ用プログラムを振り分ける。デバッグ用プログラム起動部６２，７２は、実行ユニットＡ，Ｂの各々に対応して設けられており、起動指示振り分け部６１，７１により振り分けられた起動指示に基づいて、対応する実行ユニット上でデバッグ用プログラム６３，７３を起動する。

ここで、図６に示すように、デバッグ用プログラム起動指示振り分け部６１は、通信ポート１から起動指示を受信する受信部６１１と、デバッグ用プログラム起動部６２に起動指示を送信する送信部６１４と、実行ユニット間通信を用いて他の実行ユニットＢに起動指示を送信する送信部６１２と、他の実行ユニットＢから実行ユニット間通信を用いて送信されてくる起動指示を受信する受信部６１５と、通信ポート１の通信対象の実行ユニットを変更する通信対象変更部６１３とを備えている。

また、デバッグ用プログラム起動指示振り分け部７１も同様に、受信部７１１と、送信部７１４と、送信部７１２と、受信部７１５と、通信対象変更部７１３とを備えている。

次に、図５および図７のフローチャートを参照して本実施形態のデバッグシステムの全体動作について説明する。

まず、外部の制御端末（図示せず）において入力された起動指示が、通信ポート１に対して送られてくる。この起動指示には、デバッグ用プログラムを起動する実行ユニットを指定する符号と、起動するデバッグ用プログラムの種別を指定する符号とが含まれている。

ここで、デバッグ用プログラム起動指示振り分け部６１，７１が、通信ポート１からデバッグ用プログラム起動指示を受信すると（ステップＳ１）、起動指示で指定されている、デバッグ用プログラムを起動する実行ユニットに対して、起動指示を振り分け、デバッグ用プログラム起動部６２，７２に起動指示を発行する（ステップＳ２）。その後、デバッグ用プログラム起動部６２，７２が、デバッグ用プログラム６３，７３の起動を行う（ステップＳ３）。

ここで、デバッグ用プログラム６３，７３が通信ポート１からコマンドを受信すると（ステップＳ４）、デバッグ用プログラム６３，７３により構成されるコマンド解析部（図示せず）がコマンドを解析する。通信ポート１から受信したコマンドがデバッグコマンドの場合は（ステップＳ５のＮｏ）、コマンドに応じた作業内容が実行され、デバッグ作業が行われる。ここで、作業内容によっては通信ポート１を通じてデータの送受信を行うこともある。通信ポート１から受信したコマンドが終了コマンドであった場合は（ステップＳ５のＹｅｓ）、デバッグ用プログラム６３，７３はデバッグを終了する。

ここで、コマンド解析部とは、受信したコマンドの内容を解析するための手段であり、デバッグ用プログラム６３，７３により構成される。また、コマンドの種類としては、上述した終了コマンド以外にも、メモリやレジスタの内容を読み込むコマンドや、メモリやレジスタに値を書き込むコマンドが存在する。

次に、図６および図８のフローチャートを参照して、デバッグ用プログラム起動指示振り分け部６１，７１の動作について説明する。ここでは、通信ポート１の割り込み先の初期値が実行ユニットＡであるものとして説明する。

まず、デバッグ用プログラム起動指示が通信ポート１から送られてきた場合、実行ユニットＡに対する割り込みが発生し（ステップＳ１１）、起動指示振り分け部６１が起動する。その後、受信部６１１が通信ポート１からの起動指示を受信し（ステップＳ１２）、その宛先を判定する。ここで、宛先が実行ユニットＡであった場合には（ステップＳ２１のＹｅｓ）、送信部６１４が、実行ユニットＡのデバッグ用プログラム起動部６２に対して起動指示を送信する（ステップＳ２２）。一方、宛先が実行ユニットＢであった場合には（ステップＳ２１のＮｏ）、ユニット間通信を用いる送信部６１２が、実行ユニットＢに対して起動指示を送信する（ステップＳ２３）。次に、実行ユニットＢ側の起動指示振り分け部７１が、受信部７１５によりこの起動指示を受信すると（ステップＳ２４）、通信対象変更部７１３が、通信ポート１の通信対象を実行ユニットＢに変更し（ステップＳ２５）、送信部７１４が、実行ユニットＢのデバッグ用プログラム起動部７２に対して起動指示を送信する。

なお、本実施形態では、通信ポート１からデバッグ用プログラムの起動指示を受け取ることによって、デバッグ用プログラムを起動するものとして説明した。その他にも、タイマなどを用いて起動指示を与えることにより一定時間経過後にデバッグ用プログラムを起動し、その時点での状況を確認するような構成とすることもできる。また、ブレイクポイントを設定する方法、ある地点に到達した時にデバッグ対象のプログラム自身が起動指示を発行する方法などにより、プログラムが特定地点に到達したことによって、デバッグ用プログラムを起動することとしてもよい。

また、本実施形態では、２個の実行ユニットＡ，Ｂを備えるシステムを例に挙げて説明したが、３個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

さらに、本実施形態では、デバッグ用プログラムを起動する実行ユニットが予め指定されていて、デバッグ用プログラム起動指示振り分け部６１，７１は、起動指示により指定された実行ユニットに対して起動指示を振り分けるものとして説明したが、デバッグ用プログラムを起動する実行ユニットを自動的に選択する構成とすることもできる。例えば、実行ユニットＡ，Ｂの動作状況に基づいて定められる実行ユニットに対応したデバッグ用プログラム起動部に対して起動指示を送るように、デバッグ用プログラム起動指示振り分け部６１，７１を構成することができる。ここで、実行ユニットＡ，Ｂの動作状況とは、例えば、各実行ユニットＡ，Ｂが利用する記憶領域の空き容量や、実行ユニットＡ，Ｂ間の連携の状態等を示している。

各実行ユニットＡ，Ｂの記憶領域の空き容量に基づいて振り分け先を選択する場合、例えば、各実行ユニットＡ，Ｂの記憶領域の空き容量を検出し、検出された空き容量に余裕がある実行ユニットに対応したデバッグ用プログラム起動部に対して起動指示を振り分けるように、起動指示振り分け部６１，７１を構成することができる。このような構成とするための方式としては、各実行ユニットＡ，Ｂ上の起動指示振り分け部６１，７１が空き容量の検出を行い、他の実行ユニットに対して空き容量を通知する方式や、各実行ユニットＡ，Ｂ上の起動指示振り分け部６１，７１が、他の実行ユニットが利用する記憶領域を直接参照して、単独で空き容量を検出する方式などがある。

また、本実施形態では、２個の実行ユニットＡ，Ｂが連携して動作を行うシステムを例に挙げて説明した。３個以上の実行ユニットで連携を行いながら動作するシステムに利用されるプログラムをデバッグ対象とする場合には、その連携の状態を把握して起動指示の振り分け先を決定することもできる。

この場合には、まず、各プログラムが他のプログラムとの通信経路を確保したことを検出し、デバッグ対象とする連携動作しているプログラムとの関係が無いまたは関係が少ない実行ユニット上に起動指示を振り分けるように、起動指示振り分け部６１，７１を構成することができる。ここで、通信経路が確保されたことの検出方法としては、プログラムが通信経路を確保する関数呼び出しを行ったことを検出する方法、通信経路のステータスが保存されている記憶領域を観測する方法などを採用することができる。

その逆に、デバッグ対象のプログラムが別の実行ユニット上で動作しているプログラムと連携している場合、デバッグ対象のプログラムが動作している実行ユニットだけでなく、その連携先の実行ユニットに対しても起動指示を振り分け、連携するプログラムをまとめてデバッグ対象とするような構成とすることもできる。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、デバッグ用プログラム起動指示振り分け部６１，７１とデバッグ用プログラム起動部６２，７２とを実行ユニットＡ，Ｂ上で実行されるプログラムとして構成し、起動指示の受信後に、デバッグ用プログラムを実行ユニットＡ，Ｂ上のいずれかで起動するよう構成されているため、デバッグ専用のハードウェアによりコストが増加することなく、デバッグ作業の効率化を図ることができる。

また、本実施形態では、デバッグ用プログラム起動指示振り分け部６１，７１とデバッグ用プログラム起動部６２，７２とを備えているため、任意のタイミングで任意の実行ユニット上でデバッグ用プログラムを起動することが可能となる。その結果、通常動作プログラムのみを実行した状態で不具合を発生させるか、通常動作プログラムを不具合が発生する直前まで実行し、その後に、不具合の発生原因となる処理を行っている実行ユニット上でデバッグ用プログラムを起動し、デバッグ作業を行うことが可能である。

また、本実施形態では、タイマなどを用いてデバッグ用プログラムの起動指示を与え、一定時間経過後にデバッグ用プログラムを起動する構成とすることもできる。このような構成とすることで、デバッグ作業者自身が起動指示を入力することで生じる、デバッグ用プログラムを起動するタイミングがばらつくといった影響を排除することが可能となり、また、高い時間精度で起動時間を調整することが可能となる。

また、本実施形態では、ブレイクポイントを設定する方法、ある地点に到達した時にデバッグ対象のプログラム自身が起動指示を発行する方法などにより、プログラムが特定地点に到達したことによってデバッグ用プログラムを起動する構成とすることもできる。このような構成とすることで、起動時間を調整するのみでは、観測を行いたい地点への到達時間が条件により一定にならない場合においても、観測を行いたい地点でデバッグ用プログラムを起動することが可能となる。

さらに、既に動作している通常動作プログラムによって記憶領域が使用されており、デバッグ用プログラムを追加で起動できない場合がある。一方で、デバッグ用プログラムの中には、どの実行ユニットで起動してもデバッグ作業を行えるタイプのものがある。このような場合に、本実施形態では、各実行ユニットの記憶領域の空き容量を検出し、空き容量に余裕がある実行ユニットに対して起動指示を振り分ける構成とすることもできる。このような構成とすることで、空き容量不足でデバッグ用プログラムが起動できない実行ユニットを避けて、起動指示を発行することができる。

また、連携動作しているプログラムが実行されている実行ユニット上でデバッグ用プログラムを起動すると、連携動作しているプログラムの動作に影響を与えることがあり、デバッグ作業に支障をきたすことがある。このような場合に、本実施形態では、連携の状態を把握して起動指示を発行する構成とすることもできる。このような構成とすることで、連携動作しているプログラムが実行されている実行ユニットとは異なる実行ユニット上でデバッグ用プログラムを起動することができる。

（第２の実施形態）
次に、本発明の第２の実施形態のデバッグシステムについて図面を参照して説明する。

上記で説明した第１の実施形態は、通信ポートの通信対象の実行ユニットを変更できるシステムに対して本発明を適用した場合であった。しかし、システムによっては、通信ポートの通信対象の実行ユニットを変更できない、つまり通信ポートの通信対象の実行ユニットが固定されているようなシステムも存在する。このようなシステムに対して本発明を適用した場合、デバッグ用プログラム起動指示振り分け部を各実行ユニットに対して設けたとしても、通信ポートの通信対象となっていない実行ユニット上で起動されたデバッグ用プログラムに対してコマンドを送信することができない。

本実施形態のデバッグシステムは、通信ポートの通信対象の実行ユニットが固定されているシステムに対して適用可能な構成となっている。

図９に示すように、本実施形態のデバッグシステムは、図５に示された第１の実施形態における構成と比較して、他の実行ユニットで実行されるデバッグ用プログラムの通信を中継する中継部６５を追加した構成となっている。

中継部６５は、２つの実行ユニットＡ，Ｂのうちの実行ユニットＡ上で実行されるものであり、通信ポート１からデバッグ用プログラム６３，７３に対して送信されるコマンドを、起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する。

本実施形態における通信ポート１は、通信対象の実行ユニットが実行ユニットＡに固定されている。そして、中継部６５は、通信ポート１からのコマンドの宛先が実行ユニットＡの場合には、そのコマンドを実行ユニットＡのデバッグ用プログラム６３に送信し、また、通信ポート１からのコマンドの宛先が実行ユニットＢの場合には、そのコマンドを実行ユニットＢのデバッグ用プログラム７３に送信する。

本実施形態における起動指示振り分け部６１，７１は、図６に示した起動指示振り分け部６１，７１のうち、通信対象変更部６１３，７１３と、実行ユニットＡ側のユニット間通信受信部６１５と、実行ユニットＢ側のユニット間通信送信部７１２および通信ポート受信部７１１とを省略することができる。

本実施形態における全体動作は、本発明の第１の実施形態と同一である。起動指示振り分け部６１，７１の動作は、図８における通信ポートの通信対象を変更するステップがないことを除いて本発明の第１の実施形態と同一である。

また、本実施形態では、２個の実行ユニットＡ，Ｂを備えるシステムを例に挙げて説明したが、３個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、実行ユニットＡ用プログラム領域６に、デバッグ用プログラム６３，７３への通信を中継する中継部６５が備えられ、この中継部６５が、実行ユニットＢで実行されるデバッグ用プログラム７３の通信を中継するように構成されている。そのため、通信ポート１の通信対象の実行ユニットが実行ユニットＡに固定されていて変更できないようなシステムに対しても、本発明を適用することが可能となる。また、通信ポート１と直接通信していない実行ユニットＢ上のデバッグ用プログラム７３も中継部６５によって通信が可能となるため、複数の実行ユニットＡ，Ｂで同時に複数のデバッグ用プログラム６３，７３を利用することが可能となる。

（第３の実施形態）
次に、本発明の第３の実施形態のデバッグシステムについて図面を参照して説明する。

本実施形態のデバッグシステムは、第１の実施形態のデバッグシステムと同様に、通信ポートの通信対象の実行ユニットの変更が可能なシステムに対して本発明を適用したものである。

通信ポートの通信対象の実行ユニットの変更が可能なシステムでは、デバッグ用プログラムに対するコマンドは、通信ポートの切り替えにより送信することが可能である。しかし、複数のデバッグ用プログラムを同時に起動させるような場合、通信ポートの切り替えが煩雑に発生することが予想される。また、通信ポートの通信対象の実行ユニットを変更する処理には、ある程度のオーバヘッドが必要となる。

そのため、通信ポートの通信対象の実行ユニットを変更可能な場合であっても、図９に示した第２の実施形態のデバッグシステムにおける中継部を用いて、デバッグ用プログラムへの各種コマンドを中継した方が、通信ポートを切り替える処理が不要となり処理の軽減を図ることが可能となる。

しかし、この中継部をある特定の実行ユニットにしか備えないような構成を採用した場合、中継部が備えられた実行ユニットがストール状態となると、中継部自体も機能しなくなってしまう。

そのため、本実施形態のデバッグシステムは、どの実行ユニットがストール状態になった場合でも、デバッグ用プログラムへの各種コマンドを中継することが可能なように、中継部を各実行ユニット毎に設けた構成になっている。

以下では、説明の都合により、３つの実行ユニットＡ，Ｂ，Ｃが存在するシステムに対して本発明を適用した場合について説明する。

図１０に示すように、本実施形態のデバッグシステムは、図５に示された第１の実施形態における構成と比較して、実行ユニットＣ用プログラム領域８を新たに追加し、さらに、他の実行ユニットで実行されるデバッグ用プログラムの通信を中継するための実行ユニットＡ側の中継部６５、実行ユニットＢ側の中継部７５、および実行ユニットＣ側の中継部８５を追加した構成となっている。

本実施形態における中継部６５，７５，８５は、３つの実行ユニットＡ，Ｂ，Ｃ上でそれぞれ実行されるものであり、通信ポート１からデバッグ用プログラム６３，７３，８３に対して送信されるコマンドを、起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する。

実行ユニットＣ用プログラム領域８は、デバッグ用プログラム起動指示振り分け部８１と、デバッグ用プログラム起動部８２と、デバッグ用プログラム８３と、通常動作プログラム８４とを備えている。これらは実行ユニットＣ上で実行されるプログラムとして構成されている。

本実施形態における起動指示振り分け部６１，７１の動作は、本発明の第１の実施形態と同様である。また、起動指示振り分け部８１の動作は、起動指示振り分け部６１，７１と同様である。ただし、起動指示振り分け部６１，７１，８１の動作における通信ポート１の通信対象を変更するステップについては、２つ目以降のデバッグ用プログラムを起動する場合には切り替えが無駄であることも考えられるため、実行しなくてもよい。

また、本実施形態では、３個の実行ユニットＡ，Ｂ，Ｃを備えるシステムを例に挙げて説明したが、４個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、各実行ユニットＡ，Ｂ，Ｃ毎に、デバッグ用プログラムへの通信を中継する中継部６５，７５，８５を備え、他の実行ユニットで実行されるデバッグ用プログラムの通信をいずれの実行ユニットでも中継可能なように構成されている。そのため、ある実行ユニットがストール状態になった場合でも、通信ポート１の通信対象の実行ユニットＡ，Ｂ，Ｃの煩雑な切り替えを不要としつつ、複数の実行ユニットＡ，Ｂ，Ｃで同時に複数のデバッグ用プログラム６３，７３，８３を利用することができる。

例えば、図１０に示した本実施形態のデバッグシステムにおいて、３つのデバッグ用プログラム６３，７３，８３をそれぞれ起動した場合を例に挙げて説明する。

図１０の例では、通信ポート１の通信対象実行ユニットとして実行ユニットＡが設定されている。そのため、実行ユニットＡに対して備えられた中継部６５を経由して、デバッグ用プログラム６３、デバッグ用プログラム７３、およびデバッグ用プログラム８３に対して各種コマンドが中継される。ここで、実行ユニットＡが何等かの理由によりストール状態となってしまった場合、中継部６５も機能しなくなってしまう。そのため、通信ポート１の通信対象の実行ユニットを、実行ユニットＡから実行ユニットＢに変更し、実行ユニットＢに対して備えられている中継部７５を経由して、デバッグ用プログラム７３，８３への各種コマンドの中継を行うようにすればよい。そうすれば、デバッグ用プログラム７３との通信においては実行ユニットＢへ、デバッグ用プログラム８３との通信においては実行ユニットＣへというように、各通信毎に通信ポート１における通信対象の実行ユニットを切り替える煩雑な処理を必要とすることなく、２個の実行ユニットＢ，Ｃで同時にデバッグ用プログラムの起動を行うことが可能となる。

（第４の実施形態）
次に、本発明の第４の実施形態のデバッグシステムについて図面を参照して説明する。

上記第１から第３の実施形態では、デバッグ用プログラム起動指示により指定された実行ユニットまたは起動指示振り分け部により選択された実行ユニットに対して、デバッグ用プログラム起動指示が振り分けられていた。しかし、デバッグ用プログラムを起動しようとした実行ユニットが既にストール状態となっていて、デバッグ用プログラムの起動が不可能な場合がある。

本実施形態のデバッグシステムは、このような弊害の発生を防ぐため、デバッグ用プログラムを起動可能な実行ユニットを選定する際に、ストール状態となってデバッグ用プログラムの起動が不可能な実行ユニットが選択されないような構成になっている。

図１１に示すように、本実施形態のデバッグシステムは、図５に示された第１の実施形態における構成と比較して、ストールしている実行ユニットを避けて、プログラムを実行可能な実行ユニットの起動指示振り分け部に起動指示が送られるような処理を行うストール発生実行ユニット回避部（図１１中では、回避部と表示する。）６６，７６を備える構成となっている。

ストール発生実行ユニット回避部６６，７６は、デバッグ用プログラムを起動可能な複数の実行ユニットＡ，Ｂ毎にそれぞれ配置されている。そして、ストール発生実行ユニット回避部６６，７６は、ストール状態の実行ユニットに対して起動指示が送られないような処理を行っている。

具体的には、実行ユニットＡのストール発生実行ユニット回避部６６は、起動指示の振り分け元の実行ユニット（つまり、通信ポート１の通信対象の実行ユニット）を実行ユニットＡにするよう通信ポート１に対して通知し、実行ユニットＢのストール発生実行ユニット回避部７６は、起動指示の振り分け元の実行ユニットを実行ユニットＢにするよう通信ポート１に対して通知する。

図４のように２個の実行ユニットＡ，Ｂを備えるシステムでは、実行ユニットＡ，Ｂ，Ａ，Ｂ，…，Ａ，Ｂのように交互に、ストール発生実行ユニット回避部６６，７６が起動されるよう構成する。また、３個以上の実行ユニットを備えるシステムでは、それぞれ順番に、タイマを利用するか、通常動作時に利用されているタイマ割り込みハンドラ内のプログラムによってストール発生実行ユニット回避部が起動されるよう構成する。なお、ストール発生実行ユニット回避部６６，７６の具体的な実現方法としては、交互に起動したり、順番に起動したりする必要は必ずしもないが、後述する不具合検出部と効果的に組み合わせるために、このように構成することが望ましい。

タイマ割り込みハンドラとは、タイマ割り込みが発生した場合に、その割り込みを処理するために最初に起動されるプログラムのことである。このタイマ割り込みハンドラは、タイマ割り込み機能を備えた実行ユニットであれば、一般的に使用されるプログラムである。

本実施形態における全体の動作については、図７のフローチャートにおける起動指示受信前に、デバッグ用プログラムを起動可能な実行ユニットを選定するステップが追加されることを除いて本発明の第１の実施形態と同一である。

次に、ストール発生実行ユニット回避部６６，７６の動作について図１２を参照して説明する。なお、図１２において、ステップＳ７１とステップＳ７４は意図的に選択するものではなく、その時点での状況によって必然的に選択される処理である。つまり、ステップＳ７２は実行ユニットＡによって実行される処理であるが、実行ユニットＡがストールしている場合はプログラムが実行されない。そのため、ステップＳ７１の分岐は、ステップＳ７２の処理が行われずにステップＳ７３に進んでしまうことを示す。同様に、ステップＳ７５は実行ユニットＢによって実行される処理であるが、実行ユニットＢがストールしている場合はプログラムが実行されない。そのため、ステップＳ７４の分岐は、ステップＳ７５の処理が行われずにステップＳ７６に進んでしまうことを示す。ここでは、デバッグ用プログラムの起動指示の振り分け元の実行ユニット（つまり、通信ポート１の通信対象の実行ユニット）の初期値がＢであるものとして説明する。

まず、ステップＳ７１の段階で、実行ユニットＡがストールしていない場合（ステップＳ７１のＮｏ）、実行ユニットＡ上のストール発生実行ユニット回避部６６が、デバッグ用プログラム起動指示の振り分け元となる実行ユニットの設定値を実行ユニットＡに変更する（ステップＳ７２）。この処理は、通信ポート１の通信対象を変更することで行われる。ここで起動指示があった場合（ステップＳ７３のＹｅｓ）、設定された実行ユニット（ここでは実行ユニットＡ）へ起動指示が送信される（ステップＳ７７）。

一方、ステップＳ７３で起動指示がなかった場合（ステップＳ７３のＮｏ）、実行ユニットＢがストールしていなければ（ステップＳ７４のＮｏ）、実行ユニットＢ上のストール発生実行ユニット回避部７６が、デバッグ用プログラム起動指示の振り分け元となる起動ユニットを実行ユニットＢに変更する（ステップＳ７５）。ここで起動指示があった場合（ステップＳ７６のＹｅｓ）、設定された実行ユニット（ここでは実行ユニットＢ）へ起動指示が送信される（ステップＳ７７）。起動指示がない場合は（ステップＳ７６のＮｏ）、初めに戻る。

ここで、ステップＳ７１の段階で実行ユニットＡがストールしていた場合、ステップＳ７２の処理が行われずにステップＳ７３に進むが、ここで起動指示があった場合、デバッグ用プログラムの起動指示の振り分け元である実行ユニットは実行ユニットＢである。そのため、ストールした実行ユニットＡにデバッグ用プログラム起動指示が送信され、起動ができなくなる状況を避けることができる。また、ステップＳ７４の段階で実行ユニットＢがストールしていた場合も、同様の仕組みにより、実行ユニットＢにデバッグ用プログラムの起動指示が送信され、起動ができなくなる状況を避けることができる。

この方法は、実行ユニットが３個以上の場合でも容易に拡張可能であり、実行ユニットのいずれかが動作していれば、動作している実行ユニットがデバッグ用プログラムの起動指示の振り分け元となるよう設定される。

ただし、次の場合について注意が必要である。

１つの注意点は、ステップＳ７２においてデバッグ用プログラムの起動指示の振り分け元となる実行ユニットを実行ユニットＡに変更した後、ステップＳ７３において起動指示を受け取る前に実行ユニットＡがストールする場合である。これは、ステップＳ７５とステップＳ７６の間においても同様である。この場合、デバッグプログラムの起動指示が受理されないが、一定時間を経過すると、ストールしていない実行ユニットによって起動指示の振り分け元となる実行ユニットが変更されるため、起動に失敗した場合には一定時間後に起動指示を再発行するような構成とすることが望ましい。また、全ての実行ユニットがストールした場合に備えて、一定回数の起動指示の再発行によっても起動しない場合は処理を終了し、エラー報告をするような構成としてもよい。

他の注意点は、これまでの手法によりデバッグ用プログラム起動指示振り分け部までの実行は可能であるものの、起動指示で指定しているデバッグ用プログラムを起動する実行ユニットがストールしている場合には起動ができないことである。この場合、一定時間後に起動が確認できない場合はエラー報告をするような構成としてもよい。ただし、後述する不具合検出・起動指示生成部の不具合検出手法によってストールを検出し、起動できないと判定されている場合には、即座にエラー報告をし、別の実行ユニットでデバッグ用プログラムを起動するなどの手法を用いることが望ましい。

また、起動する実行ユニットを別途指定する必要がないように、デバッグ用プログラムが起動している実行ユニットとは異なる、デバッグ対象の実行ユニットに関わる記憶領域を参照し、デバッグ対象の実行ユニットやその実行ユニットで動作しているプログラムの状態を解析するデバッグ用プログラムを起動するなどして、起動指示振り分け元の実行ユニット上でデバッグ用プログラムを起動するような構成とすることが望ましい。この場合は、起動指示振り分け部の機能のうち、起動指示を他の実行ユニットに対して転送する機能を不要とすることもできる。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、ストール発生実行ユニット回避部６６，７６により、デバッグ用プログラムを実行不可能な実行ユニットに対して起動指示が送られないように構成されているため、不具合によって実行ユニットがストールし、実行ユニットの動作に影響が出るような場合でも、利用可能な実行ユニットがあれば、その実行ユニット上でデバッグ用プログラムを起動することが可能となる。

（第５の実施形態）
次に、本発明の第５の実施形態について説明する。

上記第１から第４の実施形態では、デバッグ用プログラムは、起動された実行ユニットに関わる記憶領域しか参照することができなかった。しかし、記憶領域をどのように使用しているかを参照することにより、デバッグ対象の実行ユニットで動作しているプログラムの状態を解析することが可能になる場合がある。

本実施形態のデバッグシステムは、デバッグ対象の実行ユニットの記録領域をデバッグ用プログラムが起動された実行ユニットから参照してデバッグ作業を行うことを可能にする構成となっている。

図１３に示すように、本実施形態のデバッグシステムは、図５に示された第１の実施形態における構成と比較して、デバッグ用プログラム６３，７３を、それぞれデバッグ用プログラム６７，７７に置き換えた構成となっている。

デバッグ用プログラム６７は、状態を解析するために、物理・仮想アドレス変換部６７１と、情報抽出部６７２とを備えている。

物理・仮想アドレス変換部６７１は、仮想アドレスを物理アドレスに変換する。

情報抽出部６７２は、物理・仮想アドレス変換部６７１により変換された物理アドレスを用い、ＯＳ（Operating System）などが管理情報をメモリに配置する構造を考慮して、通常動作プログラム７４が使用している記憶領域から必要情報を抽出する。

また、デバッグ用プログラム７７も同様に、物理・仮想アドレス変換部７７１と、情報抽出部７７２とを備えている。

以下では、実行ユニットＡ上でデバッグ用プログラムを起動する場合の動作を例に挙げて説明するが、実行ユニットＢ上でデバッグ用プログラム７７を起動する場合の動作も同様である。

物理・仮想アドレス変換部６７１は、仮想アドレスと物理アドレスのオフセット（差分）情報を加減することにより、仮想アドレスと物理アドレスの相互変換を行う第１の物理・仮想アドレス変換動作と、物理・仮想変換テーブルの情報を解析することにより仮想アドレスと物理アドレスを対応づける第２の物理・仮想アドレス変換動作とを行う。

まず、第１の物理・仮想アドレス変換動作について説明する。

第１の物理・仮想アドレス変換動作は、ＯＳのカーネルが静的に確保する領域など、広範囲に渡って連続する物理アドレスが確保されている領域（以後、連続領域とする）に対応するための動作である。

連続領域において、ある仮想アドレスに対応する物理アドレスが分かった場合に、仮想アドレスと物理アドレスの差分を求めることができる。連続領域では、仮想アドレスをｎ単位増加させた場合に対応する物理アドレスもｎ単位増加したものになる。そのため、仮想アドレスと物理アドレスの差分を保持し、これを加減することで、仮想アドレスから物理アドレスへの変換、物理アドレスから仮想アドレスの変換を行うことが可能となる。

また、仮想アドレスと物理アドレスの差分は別途計算しておいたものを用いることもできるが、連続領域の先頭に対応する仮想アドレスが予め決まっているＯＳがある。この場合、各ＣＰＵに割り当てられる記憶領域の先頭の物理アドレス情報を元に差分を計算することが可能となる。そのため、デバッグ用プログラムの起動時に、各ＣＰＵに割り当てられている記憶領域の先頭の物理アドレス情報を取得可能とし、自動的に差分を計算可能にする構成とすることが望ましい。

次に、第２の物理・仮想アドレス変換動作について図１４を用いて説明する。

第２の物理・仮想アドレス変換動作は、高機能ＯＳなどで用いられる手法であって、物理・仮想アドレステーブルを用いてユーザプログラムなどの仮想アドレス管理を行う手法に対応するための動作である。ユーザプログラムなどでは、連続する仮想アドレスに対応する記憶領域が連続しているとは限らず、物理アドレスが差分により一意に決まらないため、複数の手順を要する。

第２の物理・仮想アドレス変換動作では、まず、第１の物理・仮想アドレス変換動作を利用して、ＯＳが保持している物理・仮想アドレス変換テーブルの物理アドレスを取得する（ステップＳ１０１）。

この物理アドレスを用いて物理・仮想アドレス変換テーブルを参照し、物理・仮想アドレス変換テーブルの内容を取得する（ステップＳ１０２）。

高機能ＯＳでは、物理・仮想変換テーブルが複数の層で構成されているものがあり、一度の参照で変換が完了するとは限らない。そのため、変換が完了しない場合（ステップＳ１０３のＮｏ）、物理・仮想変換テーブルの内容から次に参照すべき物理・仮想変換テーブルの仮想アドレスを取得する（ステップＳ１０４）。

これらの処理を繰り返し、目的の物理アドレスが得られた場合（ステップＳ１０３のＹｅｓ）、得られた物理アドレスの通知を行い（ステップＳ１０５）、第２の物理・仮想アドレス変換動作を終了する。

次に、情報抽出部６７２の動作について図１５を用いて説明する。

まず、基点となるデータ構造が存在する仮想アドレスを元に、物理・仮想アドレス変換を行うことによって（ステップＳ２０１）、参照するデータが存在する物理アドレスを取得する。

データを直接参照可能な物理アドレスがマッピング可能である場合、参照するデータと同一または類似の構造をもつ構造体の変数を該当する物理アドレスにマッピングするなどの方法で必要なデータに容易にアクセス可能なように構成し（ステップＳ２０２）、データを参照する（ステップＳ２０３）。

または、参照するデータと同一または類似の構造をもつ変数を予め用意し、取得された物理アドレスを用いて、参照するデータを用意した変数の領域にコピーし、そのデータを参照を行うこととしてもよい。この場合、物理アドレスがデータを直接参照できないものであっても、そのデータを参照することが可能になるが、コピーを行うオーバヘッドが発生するという欠点も生じる。

データ構造が単純な場合、これらの処理で抽出が終了し（ステップＳ２０４のＹｅｓ）、抽出結果を通知（ステップＳ２０６）することで処理が完了する。ただし、データによっては、リスト構造などのデータが分散した状態で配置されているものがある。

最初の参照で必要データがないかまたは一部しか揃っていない場合（ステップＳ２０４のＮｏ）、次のリストの場所を示すアドレスを取得する（ステップＳ２０５）。このアドレスは仮想アドレスで記載されているため、物理・仮想アドレス変換を行うことによって、物理アドレスを取得し（ステップＳ２０１）、次のリストの内容を参照する（ステップＳ２０２，Ｓ２０３）。この処理を必要なデータが揃うまで複数回繰り返す。

なお、本実施形態では、仮想アドレスを用いるＯＳ以外では、これらの処理のうちステップＳ２０１の物理・仮想アドレス変換は必要がなく、これを除いた処理によって同様の機能を実現することができる。

また、本実施形態では、２個の実行ユニットＡ，Ｂを備えるシステムを例に挙げて説明したが、３個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

本実施形態では、デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象の実行ユニットに関わる記憶領域を参照することで、デバッグ対象の実行ユニットやその実行ユニットで動作しているプログラムの状態を解析するデバッグ用プログラムを備えている。そのため、デバッグ対象の実行ユニットの状態の如何にかかわらずデバッグ作業を行うことが可能となる。

一方で、実行ユニットが備えるレジスタやキャッシュメモリなどの資源は、実行ユニットが使用する記憶領域を参照するだけでは確認することができない。そして、レジスタの内容が参照できないことにより、必要なデバッグ情報が得られないという弊害や、キャッシュメモリに最新の情報がとどまり続けることにより、記憶領域を参照するだけでは最新の情報が確認できないなどの弊害が生じる可能性がある。

そのため、本実施形態では、デバッグ対象である実行ユニット上で、実行ユニットが備えるレジスタやキャッシュメモリの読み書き、制御などを行う実行ユニット内資源管理部（図示せず）を、デバッグ用プログラムにより構成するようにしてもよい。この実行ユニット内資源管理部は、レジスタ内容読み出し・書込み部（図示せず）と、キャッシュメモリ管理部（図示せず）とから構成されている。

レジスタ内容の読み出しを行う場合、デバッグ対象とする実行ユニット上のデバッグ用プログラムに読み出し指示を与え、レジスタ内容読み出し・書込み部により読み出しを行わせ、その結果を通知させる。書き込みを行う場合は、デバッグ対象とする実行ユニット上のデバッグ用プログラムに書き込み指示と書き込むデータを与え、レジスタ内容読み出し・書込み部により書き込みが行わせる。

また、キャッシュメモリ管理部は、キャッシュ内容の吐き出し指示を受け取ると、実行ユニットにキャッシュメモリ吐き出し命令を実行するように制御を行う。キャッシュメモリの吐き出しが完了すると、メモリ上に最新の情報が書き込まれる。そのため、その後、情報を取得するデバッグ用プログラムが、他の実行ユニット上の記憶領域を観測することも可能となる。または、デバッグ対象の実行ユニット上のデバッグ用プログラムが、読み出したキャッシュメモリの内容を外部に通知するような構成とすることもできる。また、キャッシュメモリの動作モードの制御や、内容の更新なども制御可能なように構成することが望ましい。

さらに、デバッグ対象の実行ユニット上でデバッグ用プログラムを実行中は、その実行ユニットが備えるレジスタのうち、演算に用いるレジスタやプログラムカウンタなどのプログラムの進行に関わるレジスタなどの内容は、記憶領域のスタック領域に退避されている。しかし、そのスタック領域の内容がキャッシュメモリ上に残っており、記憶領域上には最新の値が保存されていない可能性がある。そのため、上記のキャッシュメモリ管理部を用いることによって、キャッシュメモリの内容を記憶領域上に吐き出すか、キャッシュメモリの内容を直接読み出すことにより、退避されたレジスタの内容を取得するような構成とすることができる。それにより、デバッグ対象プログラムの実行中に保持されていたレジスタ内容を取得することができる。

このような構成とすることにより、デバッグ対象の実行ユニットでデバッグ用プログラムを利用可能である場合には、デバッグ対象の実行ユニット上の、レジスタ内容読み出し・書込み部およびキャッシュメモリ管理部を備えるデバッグ用プログラムを利用し、記憶領域を参照することができる。それにより、情報を取得するデバッグ用プログラムが、通常は実行できないレジスタやキャッシュメモリの読み書き、制御などを実現可能となる。

（第６の実施形態）
次に、本発明の第６の実施形態のデバッグシステムについて説明する。

上記で説明した第１〜第５の実施形態では、実行ユニットに何らかの不具合が発生した場合には、外部の制御端末から起動指示を入力する必要があった。

本実施形態のデバッグシステムは、実行ユニットに何等かの不具合が発生した場合には、外部の制御端末から起動指示を入力しない場合であっても、自動的に起動指示が生成される構成となっている。

図１６に示すように、本実施形態のデバッグシステムは、図５に示した第１の実施形態のデバッグシステムにおける構成と比較して、不具合の発生を検出する不具合検出部６８，７８を追加した構成となっている。

不具合検出部６８，７８は、実行ユニットＡ，Ｂにおいて不具合が発生したことを検出すると、デバッグ用プログラムの起動指示を生成する。

ここで、不具合検出部６８，７８によって不具合を検出したことを外部の制御端末に通知することのみを行うようシステムを構成してもよい。ただし、不具合発生を検出した時点で不具合が発生した実行ユニットやプログラム、不具合を発生させる原因となる実行ユニットやプログラム、またはその他の実行ユニットやプログラムを停止させる手段を設けた構成とすることが望ましい。

なお、不具合検出部６８，７８が備えられる実行ユニットは、デバッグ用プログラム起動部６２，７２が備えられる実行ユニットと必ずしも一致している必要はなく、実行ユニットＡ，Ｂのどちらか片方にのみ備えられていてもよい。

本実施形態における全体の動作については、不具合検出部６８，７８によって不具合を検出するステップが、デバッグ用プログラム起動指示を受信するステップの前に追加されることを除いて、上記で説明したいずれかの実施形態と同一である。

次に、不具合検出部６８，７８の構成・動作について説明する。

不具合には、不具合の発生がシステムにより報告される不具合（以下、実行時エラーと称する。）と、システムによる報告が行われず、正常動作を妨げる不具合とがある。実行時エラーには、不正メモリ参照、不正命令実行、ハードウェア例外などがある。正常動作を妨げる不具合には、無限ループなどによるストールや、暴走などがある。

まず、実行時エラーを対象とする不具合検出部６８，７８の第１の構成について説明する。この場合の不具合検出部６８，７８は、システムにより報告される不具合を受信する不具合受信部（図示せず）と、不具合発生を通知する通知部（図示せず）とから構成される。ここで、実行時エラーが発生した場合に特定のプログラムが実行されるように構成されているシステムにおいては、この特定のプログラム内に不具合検出部を設けてもよい。

実行時エラーを対象とするために、実行ユニット上のプログラムとして不具合検出部を設けた場合、実行時エラーが発生した実行ユニットの不具合検出部によって不具合が検出される。この場合、デバッグ用プログラムを起動する実行ユニットを、不具合の発生した実行ユニットにして起動指示を生成することとしてもよい。一方で、実行時エラーが発生した実行ユニット上でデバッグ用プログラムを起動する場合、プログラムの起動が実行ユニットや記憶領域に与える影響によって不具合の原因が判別できなくなる可能性もある。このような場合には、別の実行ユニットに対してデバッグ用プログラムの起動指示を発行し、第５の実施形態におけるデバッグ用プログラム６７，７７を起動するような構成とすることが望ましい。

次に、正常動作を妨げる不具合を対象とする不具合検出部６８，７８の第２の構成について説明する。この場合の不具合検出部６８，７８は、デバッグ対象の実行ユニット上で実行されるプログラムによって更新される情報を読み出す更新情報読出し部（図示せず）と、情報の更新が正常に行われているかどうかを確認する正常更新確認部（図示せず）と、不具合発生を通知する不具合発生通知部（図示せず）とから構成される。

次に、不具合検出部６８，７８の第２の構成の動作について図１７を参照して説明する。ここでは、不具合発生通知部を、不具合発生確認後にデバッグ用プログラムの起動指示を生成するデバッグ用プログラム起動指示生成部として設けた場合を例に挙げて説明する。

まず、更新情報読出し部が、他の実行ユニット上で実行されるプログラムによって更新される情報を読み出す（ステップＳ３０１）。この情報を元に、正常更新確認部が、更新が正常に行われているかどうかを確認する（ステップＳ３０２）。更新が正常に行われている場合（ステップＳ３０３のＹｅｓ）、正常更新確認部は次の更新を確認する。不具合の発生により更新が異常であることが検出されると（ステップＳ３０３のＮｏ）、デバッグ用プログラム起動指示生成部が、デバッグ用プログラム起動指示を生成し（ステップＳ３０４）、デバッグ用プログラム起動部に起動指示を与える。なお、プログラムによって更新される情報は、情報を更新するプログラムを設けて取得することにしてもよい。ただし、ＯＳが内部で使用する時刻情報をプログラムによって更新される情報として用いることで、別途プログラムを設けずに不具合検出部を構成することができる。

次に、正常動作を妨げる不具合を対象とする不具合検出部６８，７８の第３の構成について説明する。この場合の不具合検出部６８，７８は、デバッグ対象の実行ユニットに対して割り込みを発生させる割り込み生成部（図示せず）と、デバッグ対象の実行ユニットからの応答を確認する応答確認部（図示せず）と、デバッグ用プログラムの起動指示を生成する起動指示生成部（図示せず）とから構成される。また、デバッグ対象の実行ユニットは割り込みに対する応答部を備える。

次に、不具合検出部の第３の構成の動作について図１８を参照して説明する。

まず、割り込み生成部が、他の実行ユニットに対して割り込みを発生させ（ステップＳ３１１）、応答が返ってくるのを待つ（ステップＳ３１２）。規定時間内に応答を受信した場合は（ステップＳ３１３のＹｅｓ）、正常であると判断し、次の割り込みを発生させる。規定時間内に応答が返ってこない場合（ステップＳ３１３のＮｏ）、不具合により応答不能になったと判断し、起動指示生成部が、デバッグ用プログラムの起動指示を生成し（ステップＳ３１４）、デバッグ用プログラム起動部に起動指示を与える。なお、ここでは判断基準を規定時間内に応答が返ってくることとしたが、返ってきた応答が正常であるか異常であるかを判断基準とすることもできる。

次に、正常動作を妨げる不具合を対象とする不具合検出部６８，７８の第４の構成について説明する。この構成は、ストールが発生している実行ユニットを避けてデバッグ用プログラムを起動可能な実行ユニットを選定するストール発生実行ユニット回避部（図１１のストール発生実行ユニット回避部６６，７６）に、現在どの実行ユニットが選定されているかを検査する手段を追加することで実現される。

次に、不具合検出部６８，７８の第４の構成の動作について図１９を参照して説明する。

不具合検出部６８，７８の第４の構成では、図１２におけるストール発生実行ユニット回避部６６，７６の動作に加えて、図１９のように、ストール発生実行ユニット回避部６６，７６によって設定されている現在の実行ユニットがどれであるかを判定するステップＳ７８，Ｓ７９が追加されている。

なお、図１９において、ステップＳ７１とステップＳ７４は意図的に選択するものではなく、その時点での状況によって必然的に選択される処理である。つまり、ステップＳ７２は実行ユニットＡによって実行される処理であるが、実行ユニットＡがストールしている場合はプログラムが実行されない。そのため、ステップＳ７１の分岐は、ステップＳ７２の処理が行われずにステップＳ７３に進んでしまうことを示す。同様に、ステップＳ７５は実行ユニットＢによって実行される処理であるが、実行ユニットＢがストールしている場合はプログラムが実行されない。そのため、ステップＳ７４の分岐は、ステップＳ７５の処理が行われずにステップＳ７６に進んでしまうことを示す。ここでは、デバッグ用プログラム起動指示の振り分け元となる実行ユニットの初期値が実行ユニットＢであるものとして説明する。

まず、実行ユニットＡがストールしていない場合（ステップＳ７１のＮｏ）、初期設定値は実行ユニットＢであるので（ステップＳ７８のＹｅｓ）、実行ユニットＡ上のプログラムが、デバッグ用プログラムの起動指示の振り分け元となる実行ユニットを実行ユニットＡに変更する（ステップＳ７２）。一方、実行ユニットＡがストールしていた場合（ステップＳ７１のＹｅｓ）、ステップＳ７２の処理が行われずにステップＳ７３に進む。ここで起動指示がない場合（ステップＳ７３のＮｏ）、実行ユニットＢがストールしていなければ（ステップＳ７４のＮｏ）、ステップＳ７９の検査に進む。ステップＳ７９では、起動指示の振り分け元として設定されている実行ユニットを検査する。この検査では、設定されている実行ユニットがＡであれば（ステップＳ７９のＹｅｓ）、正常である。しかし、実行ユニットＡでない場合は（ステップＳ７９のＮｏ）、ステップＳ７２が実行されなかったことになるため、実行ユニットＡの不具合を検出できる。この場合には、ステップＳ７７に進み、設定されている実行ユニット（この場合、実行ユニットＢ）に起動指示が送信され、デバッグ用プログラムを起動する。ここで、実行ユニットＢがストールしていた場合には（ステップＳ７４のＹｅｓ）、同様にステップＳ７８にて不具合が検出され（ステップＳ７８のＮｏ）、デバッグ用プログラムが起動される。

なお、上記の不具合検出部の第１〜第４の構成は、互いに排他的なものではなく、任意に組み合わせることも可能である。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、不具合検出部６８，７８を備え、不具合の発生を確認できるような構成としているため、不具合発生の確認が困難なシステムであっても、不具合発生確認後にデバッグ用プログラムを起動してデバッグ作業を開始することができる。

また、本実施形態では、不具合発生を検出した時点で不具合が発生した実行ユニットやプログラム、不具合を発生させる原因となる実行ユニットやプログラム、またはその他の実行ユニットやプログラムを停止させる手段を設けた構成とすることもできる。このような構成とすることで、不具合発生後に処理が進んでしまうことにより、不具合発生の原因の追究が困難になることを避けることができる。

また、本実施形態では、不具合の発生を検出すると、デバッグ用プログラム起動指示を生成するよう不具合検出部６８，７８を構成することもできる。このような構成とすることで、デバッグ作業者が、デバッグ用プログラムを起動する実行ユニットやデバッグ用プログラムの種類を判断してそのデバッグ用プログラムを起動することなく、デバッグ作業を開始することができる。

（第７の実施形態）
次に、本発明の第７の実施形態のデバッグシステムについて説明する。

上記で説明した第５の実施形態のデバッグシステムによれば、ある実行ユニットがストールした場合でも、その実行ユニットに関するメモリの内容を読むことが可能となる。しかし、この第５の実施形態のデバッグシステムによっても、ストール状態となった実行ユニットのレジスタやキャッシュメモリの内容を読むことはできない。なぜならば、実行ユニットがストール状態となった場合には、一般的にレジスタやキャッシュメモリの内容の読み出しができなくなるからである。

本実施形態のデバッグシステムは、ある実行ユニットがストールした場合であっても、その実行ユニットのレジスタやキャッシュメモリの内容を読み出してデバッグを行うことを可能にする構成となっている。

図２０に示すように、本実施形態のデバッグシステムは、上記で説明した第１の実施形態における構成と比較して、実行ユニットＡ用プログラム領域６内のデバッグ用プログラム６３は、実行ユニット間割り込み生成部（図２０中では、割り込み生成部と表示する。）６３１と応答受信部６３２とを備え、また、デバッグ対象の実行ユニットで実行される割り込みハンドラ６９は、応答生成部６９１と情報取得・制御部６９２とを備える構成となっている。

実行ユニット間割り込み生成部６３１は、デバッグ対象の実行ユニットＢに対して割り込みを発生させる。応答受信部６３２は、デバッグ対象の実行ユニットＢからの応答を応答生成部７９１を経由して受信する。

情報取得・制御部６９２は、他の実行ユニットＢからの割り込みが発生した際に、レジスタ、キャッシュメモリ、フラッシュメモリ等の予め設定されたメモリ内の情報を取得する。応答生成部６９１は、情報取得・制御部６９２により得られた情報を、割り込みを発生させた実行ユニットＢに対して送信する。

なお、図５に示した第１の実施形態では、割り込みハンドラ６９は図示されていないが、割り込みハンドラは一般的な実行ユニットであれば標準的に備えられているプログラムである。

また、本実施形態のデバッグシステムは、同様にして、実行ユニットＢ用プログラム領域７内のデバッグ用プログラム７３は、実行ユニット間割り込み生成部７３１と応答受信部７３２とを備え、また、デバッグ対象の実行ユニットで実行される割り込みハンドラ７９には、応答生成部７９１と情報取得・制御部７９２とを備えた構成となっている。

なお、図２０は、本実施形態のデバッグシステムを、第１の実施形態の構成に対して適用した場合の例を示しているが、第２〜第６の実施形態に対しても同様に適用することができる。

次に、図２１のフローチャートを参照して本実施形態のデバッグシステムの動作について説明する。ここでは、実行ユニットＡのデバッグ用プログラム６３から、実行ユニットＢ側のデバッグを行う場合の例について説明する。

まず、デバッグ用プログラム６３は、対象となる実行ユニットＢに対して実行ユニット間割り込みを発行する（ステップＳ４０１）。すると、実行ユニットＢの割り込みハンドラ７９が起動する（ステップＳ４０２）。この割り込みハンドラ７９において情報取得・制御部７９２を用いることにより、実行ユニットＢのレジスタ、キャッシュメモリ、フラッシュメモリを対象として情報収集、書込み、制御などを行う（ステップＳ４０３）。その後、応答生成部７９１によって実行ユニットＡに対して応答を生成し（ステップＳ４０４）、実行ユニットＡは応答受信部６３２を用いてこれを受信する（ステップＳ４０５）。ここで、作業内容が制御のみの場合は、応答には制御の成否情報のみを含めればよい。一方、作業内容が情報収集を含む場合は、応答には収集した情報も含める。

または、実行ユニットＢ側で周期的に発生するタイマ割り込みの割り込みハンドラを割り込みハンドラ７９とし、実行ユニットＡが通信部（図示せず）を用いて、対象プロセスの実行制御を行う指示を実行ユニットＢに与える構成としてもよい。ただし、この構成の場合は、実行制御を行うタイミングが、周期的に発生するタイマ割り込みのタイミングだけになるという制約が生じる。

なお、本実施形態では、実行ユニットＢのデバッグ用プログラム７３から、実行ユニットＡ側のデバッグを行う場合の動作も、同様の仕組みで実現可能である。

また、本実施形態では、２個の実行ユニットＡ，Ｂを備えるシステムを例に挙げて説明したが、３個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、デバッグ用プログラム６３，７３は、実行ユニット間割り込み生成部６３１，７３１と応答受信部６３２，７３２とを備え、デバッグ対象の実行ユニットで実行される割り込みハンドラは、情報取得・制御部６９２，７９２と応答生成部６９１，７９１とを備えている。そして、デバッグ対象の実行ユニット以外の実行ユニット上で動作しているデバッグ用プログラムから、デバッグ対象の実行ユニットに対して割り込みを発生させ、割り込みハンドラにより情報取得や制御を行う。

上述したように、割り込みハンドラとは、割り込みが発生した場合に、その割り込みを処理するために最初に起動されるプログラムである。そのため、実行ユニットＡ，Ｂの割り込みハンドラ６９，７９内に、情報取得・制御部６９２，７９２および応答生成部６９１，７９１をそれぞれ設けることにより、実行ユニットＡ，Ｂがストール状態となった場合でもストール状態となった実行ユニットのキャッシュメモリやレジスタの内容を読むことが可能となる。

（第８の実施形態）
次に、本発明の第８の実施形態のデバッグシステムについて説明する。

上記で説明した第１〜第７の実施形態では、ある実行ユニットがストール状態となった場合に、その実行ユニットのデバッグを行うものであった。

実行ユニットがストール状態となる場合、通常動作プログラムにより実行されているあるプロセスが暴走していることが考えられる。このように、あるプロセスが暴走状態になると、他のプロセスは不具合がないにもかかわらず、実行ユニット全体としてはストール状態になり機能しなくなってしまう。

そこで、本実施形態のデバッグシステムは、あるプロセスが暴走し、実行ユニットがストール状態となった場合でも、暴走したプロセスを停止させ、不具合の修正を行うことにより、ストール状態となった実行ユニットを正常状態に復帰させる構成となっている。

本実施形態のデバッグシステムの構成を図２２に示す。図２２は、実行ユニットＢがデバッグ対象実行ユニットとなり、実行ユニットＡから実行ユニットＢに対するデバッグを行うことのみが可能な構成となっている。任意の実行ユニットから任意の実行ユニットをデバッグする場合には、同様の構成を各実行ユニットに設ける必要がある。

図２２に示すように、本実施形態のデバッグシステムは、図５に示した第１の実施形態のデバッグシステムにおける構成と比較して、デバッグ用プログラム６３は、実行ユニット間割り込み生成部（図２２中では、割り込み生成部と表示する。）６３１と応答受信部６３２とを備え、また、デバッグ対象の実行ユニットである実行ユニットＢにおいて実行される割り込みハンドラ７９は、応答生成部７９１とプロセス制御部７９３とを備えた構成となっている。

実行ユニット間割り込み生成部６３１は、デバッグ対象の実行ユニットＢに対する割り込みを発生させる。応答受信部６３２は、デバッグ対象の実行ユニットＢからの応答を応答生成部７９１を経由して受信する。

プロセス制御部７９３は、デバッグ対象の実行ユニットＢにおいて起動している通常動作プログラム７４のプロセス制御を行って、暴走しているプロセスを停止させる。応答生成部７９１は、プロセス制御部７９３によるプロセス制御の結果により得られた情報を、割り込みを発生させた実行ユニットＢに対して送信する。

次に、図２３のフローチャートを参照して本実施形態のデバッグシステムの動作について説明する。図２３は、実行ユニットＡのデバッグ用プログラム６３から、実行ユニットＢ側のプロセス制御を行う場合の例を示している。

まず、デバッグ用プログラム６３は、デバッグ対象となる実行ユニットＢに対して実行ユニット間割り込みを発行する（ステップＳ４０１）。すると、実行ユニットＢの割り込みハンドラ７９が起動する（ステップＳ４０２）。この割り込みハンドラ７９においてプロセス制御部７９３を用いることにより、実行ユニットＢで実行されている通常動作プログラム７４のプロセス制御を行う（ステップＳ４０６）。その後、応答生成部７９１によって応答を生成して実行ユニットＡに対して送信し（ステップＳ４０４）、実行ユニットＡは応答受信部６３２を用いて応答を受信する（ステップＳ４０５）。

または、実行ユニットＢ側で周期的に発生するタイマ割り込みの割り込みハンドラを割り込みハンドラ７９とし、実行ユニットＡが通信部（図示せず）を用いて、対象プロセスの実行制御を行う指示を実行ユニットＢに与える構成としてもよい。ただし、この構成の場合は、実行制御を行うタイミングが、周期的に発生するタイマ割り込みのタイミングだけになるという制約が生じる。

制御対象プロセスに対するプロセス制御を実現する具体的な方法としては、次のような方法がある。

第１のプロセス制御方法では、ＯＳのスケジューラに、スケジューラが行うプロセス制御を外部からの指示に基づいて変更するプロセス制御変更部を備えるようにする。そして、割り込みハンドラ７９内のプロセス制御部７９３からプロセス制御変更部に対し、プロセス変更指示を送信することで実現することができる。

第２のプロセス制御方法では、割り込みハンドラ７９内のプロセス制御部７９３から、ＯＳのＡＰＩ（Application Program Interface)（システムコールなど）に類似する手順により、制御対象プロセスに対してプロセス制御シグナルを発行するプロセス制御シグナル発行部を備えるようにする。そして、プロセス制御シグナル発行部が制御対象プロセスにプロセス制御シグナルを発行することで実現することができる。

第３のプロセス制御方法では、割り込みハンドラ７９内に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスを、別のアドレスに変更するアドレス変更部を備えるようにする。そして、割り込みハンドラ７９内のアドレス変更部が、戻りアドレスを不正なアドレスに変更し、不正アドレス参照例外を発生させることで実現することができる。ここで、例外を発生させる処理のみでも、例外による異常終了処理をＯＳが行うため、プロセスを終了させることができる。しかし、例外ハンドラ内で、プロセスを停止させるなどの、異常終了処理以外の制御を行わせるような構成とすることで、様々なプロセス制御を行うことが可能となる。

第４のプロセス制御方法では、割り込みハンドラ７９内に、記憶領域上に退避されている制御対象プロセスへの戻りアドレスに存在する命令を別の命令に変更する命令変更部を備えるようにする。そして、割り込みハンドラ７９内の命令変更部が、戻りアドレスに存在する命令をデバッグ命令、不正な命令などに置き換え、例外を発生させることで実現することができる。ここで、例外を発生させる処理のみでも、例外による異常終了処理をＯＳが行うため、プロセスを終了させることができる。しかし、例外ハンドラ内で、プロセスを停止させるなどの、異常終了処理以外の制御を行わせるような構成とすることで、様々なプロセス制御を行うことが可能となる。

ユーザプロセスとして構成されるデバッグ用プログラムからプロセス制御用システムコールを発行し、プロセス制御を行う既存手法がある。このような手法を用いる場合、実行ユニットで実行されているプロセスのいずれかが暴走すると、デバッグ用プログラムに制御が移らず、その結果、プロセス制御を行うことができないという弊害がある。しかし、割り込みハンドラ７９内からプロセス制御を行う上記いずれかのプロセス制御を用いる場合、割り込みハンドラ７９はユーザプロセスに比べて高い優先度で実行されるため、暴走したプロセスが存在する場合であってもプロセス制御を行うことが可能となる。

なお、本実施形態では、実行ユニットＢのデバッグ用プログラムから、実行ユニットＡ側のデバッグを行う場合の動作も、同様の仕組みで実現可能である。

また、本実施形態では、２個の実行ユニットＡ，Ｂを備えるシステムを例に挙げて説明したが、３個以上の任意の個数の実行ユニットを備えるシステムへの拡張も容易に可能である。

次に、本実施形態のデバッグシステムの効果について説明する。

本実施形態では、デバッグ対象の実行ユニットＢによって実行される割り込みハンドラ７９内にプロセス制御部７９３を備えさせ、割り込みハンドラ７９内からデバッグ対象のプロセスの制御を行うような構成としてする。そして、デバッグ対象の実行ユニットＢ以外の実行ユニットＡ上で動作しているデバッグ用プログラム６３から、デバッグ対象の実行ユニットＢに割り込みを発生させ、割り込みハンドラ７９内でプロセス制御を行うことにより、デバッグ対象の実行ユニットＢ以外の実行ユニットＡからプロセス制御を行うことが可能になる。また、ユーザプロセスよりも高い優先度で実行される割り込みハンドラ７９内からプロセス制御を行うため、暴走したプロセスが存在する場合であっても、暴走しているプロセスを停止させ、不具合が発生している状況を解析して変数内容の修正等の処理を行い、さらに再度プログラムを実行させて不具合が解消されたか否かを観察することが可能となる。そして、このような処理を繰り返すことにより、最終的にはストール状態となっていた実行ユニットを正常動作に復帰することが可能となる。

本発明は、複数の実行ユニットを備えるシステムＬＳＩ用のデバッグシステムといった用途に適用可能である。また、本発明は、複数の実行ユニットを備える組み込みシステム、複数の実行ユニットを備えるコンピュータシステム用のデバッグシステムといった用途にも適用可能である。

Claims (33)

1. 複数の実行ユニットが連携動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグシステムであって、
   デバッグ用プログラムの起動を指示する起動指示を受信すると、前記複数の実行ユニットに対して前記起動指示を振り分ける起動指示振り分け手段と、
   前記複数の実行ユニットの各々に対応して設けられ、前記起動指示振り分け手段により振り分けられた起動指示に基づいて、対応する実行ユニット上でデバッグ用プログラムを起動する複数のデバッグ用プログラム起動手段と、を備えたデバッグシステム。
2. 前記起動指示振り分け手段は、前記起動指示により指定された実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１記載のデバッグシステム。
3. 前記起動指示振り分け手段は、前記複数の実行ユニットの各々の動作状況に基づいて定められる実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１記載のデバッグシステム。
4. 前記起動指示振り分け手段は、前記複数の実行ユニットの各々が利用する記憶領域の空き容量を検出し、検出された空き容量に余裕のある実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１記載のデバッグシステム。
5. 前記起動指示振り分け手段は、デバッグ対象の実行ユニットと関係が無いまたは関係が少ない実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１記載のデバッグシステム。
6. 前記複数の実行ユニットのいずれか１つに対応して設けられ、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する中継手段をさらに備える、請求項１に記載のデバッグシステム。
7. 前記複数の実行ユニットの各々に対応して設けられ、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する複数の中継手段をさらに備える、請求項１に記載のデバッグシステム。
8. 前記起動指示がストール状態の実行ユニットに対応するデバッグ用プログラム起動手段には送信されないようにするストール発生実行ユニット回避手段をさらに備える、請求項１に記載のデバッグシステム。
9. 前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内には、
   仮想アドレスを物理アドレスに変換する物理・仮想アドレス変換手段と、
   前記物理・仮想アドレス変換手段により変換された物理アドレスを用いて、オペレーティングシステムが管理情報をメモリに配置する構造を考慮して、前記デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象の実行ユニットが利用する記憶領域から必要情報を抽出する情報抽出手段とが構成されている、請求項１に記載のデバッグシステム。
10. 前記複数の実行ユニットの中から不具合が発生した実行ユニットを検出し、検出された実行ユニットのデバッグを行うための起動指示を生成する不具合検出手段をさらに備える、請求項１に記載のデバッグシステム。
11. 前記複数の実行ユニットの各々において割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラ内には、
    他の実行ユニットからの割り込みが発生した際に、予め設定されたメモリ内の情報を取得する情報取得・制御手段と、
    前記情報取得・制御手段により取得された情報を、割り込みを発生させた実行ユニットに対して送信する応答生成手段とが構成されており、
    前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内には、
    デバッグ対象の実行ユニットに対して割り込みを発生させる実行ユニット間割り込み生成手段と、
    デバッグ対象の実行ユニットからの応答を受信する応答受信手段とが構成されている、請求項１に記載のデバッグシステム。
12. 複数の実行ユニットが連携動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグ方法であって、
    デバッグ用プログラムの起動を指示する起動指示を受信すると、前記複数の実行ユニットに対して前記起動指示を振り分けるステップと、
    前記複数の実行ユニットの各々に対応して設けられたデバッグ用プログラム起動手段が、振り分けられた前記起動指示に基づいて、対応する実行ユニット上でデバッグ用プログラムを起動するステップと、を備えたデバッグ方法。
13. 前記起動指示を振り分けるステップでは、前記起動指示により指定された実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１２に記載のデバッグ方法。
14. 前記起動指示を振り分けるステップでは、前記複数の実行ユニットの各々の動作状況に基づいて定められる実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１２に記載のデバッグ方法。
15. 前記起動指示を振り分けるステップでは、前記複数の実行ユニットの各々が利用する記憶領域の空き容量を検出し、検出された空き容量に余裕のある実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１２に記載のデバッグ方法。
16. 前記起動指示を振り分けるステップでは、デバッグ対象の実行ユニットと関係が無いまたは関係が少ない実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項１２に記載のデバッグ方法。
17. 前記複数の実行ユニットのいずれか１つに対応して設けられた中継手段が、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継するステップをさらに備える、請求項１２に記載のデバッグ方法。
18. 前記複数の実行ユニットの各々に対応して設けられた中継手段のいずれか１つが、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継するステップをさらに備える、請求項１２に記載のデバッグ方法。
19. 前記起動指示を振り分けるステップでは、前記起動指示がストール状態の実行ユニットに対応するデバッグ用プログラム起動手段には送信されないようにする、請求項１２に記載のデバッグ方法。
20. 前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内に構成された物理・仮想アドレス変換手段が、仮想アドレスを物理アドレスに変換するステップと、
    前記物理・仮想アドレス変換手段により変換された物理アドレスを用いて、オペレーティングシステムが管理情報をメモリに配置する構造を考慮して、前記デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象の実行ユニットが利用する記憶領域から必要情報を抽出するステップとをさらに備える、請求項１２に記載のデバッグ方法。
21. 前記複数の実行ユニットの中から不具合が発生した実行ユニットを検出し、検出された実行ユニットのデバッグを行うための起動指示を生成するステップをさらに備える、請求項１２に記載のデバッグ方法。
22. 前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内に構成された実行ユニット間割り込み生成手段が、デバッグ対象の実行ユニットに対して割り込みを発生させるステップと、
    前記複数の実行ユニットの各々において割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラ内に構成された情報取得・制御手段が、他の実行ユニットからの割り込みが発生した際に、予め設定されたメモリ内の情報を取得するステップと、
    前記情報取得・制御手段により取得された情報を、割り込みを発生させた実行ユニットに対して送信するステップと、
    デバッグ用プログラムが起動された実行ユニットが、デバッグ対象の実行ユニットからの応答を受信するステップとをさらに備える、請求項１２に記載のデバッグ方法。
23. 複数の実行ユニットが連携して動作するシステムにおいて実行されるプログラムのデバッグを行うためのデバッグ方法をコンピュータに実行させるためのプログラムであって、
    デバッグ用プログラムの起動を指示する起動指示を受信すると、前記複数の実行ユニットに対して前記起動指示を振り分ける処理と、
    前記複数の実行ユニットの各々に対応して設けられたデバッグ用プログラム起動手段が、振り分けられた前記起動指示に基づいて、対応する実行ユニット上でデバッグ用プログラムを起動する処理と、をコンピュータに実行させるためのプログラム。
24. 前記起動指示を振り分ける処理では、前記起動指示により指定された実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項２３に記載のプログラム。
25. 前記起動指示を振り分ける処理では、前記複数の実行ユニットの各々の動作状況に基づいて定められる実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項２３に記載のプログラム。
26. 前記起動指示を振り分ける処理では、前記複数の実行ユニットの各々が利用する記憶領域の空き容量を検出し、検出された空き容量に余裕のある実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項２３に記載のプログラム。
27. 前記起動指示を振り分ける処理では、デバッグ対象の実行ユニットと関係が無いまたは関係が少ない実行ユニットに対応するデバッグ用プログラム起動手段に対して前記起動指示を送信する、請求項２３に記載のプログラム。
28. 前記複数の実行ユニットのいずれか１つに対応して設けられた中継手段が、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する処理をさらにコンピュータに実行させる、請求項２３に記載のプログラム。
29. 前記複数の実行ユニットの各々に対応して設けられた中継手段のいずれか１つが、通信ポートからデバッグ用プログラムに対して送信されるコマンドを、前記起動指示により指定された実行ユニット上のデバッグ用プログラムに対して中継する処理をさらにコンピュータに実行させる、請求項２３に記載のプログラム。
30. 前記起動指示を振り分ける処理では、前記起動指示がストール状態の実行ユニットに対応するデバッグ用プログラム起動手段には送信されないようにする、請求項２３に記載のプログラム。
31. 前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内に構成された物理・仮想アドレス変換手段が、仮想アドレスを物理アドレスに変換する処理と、
    前記物理・仮想アドレス変換手段により変換された物理アドレスを用いて、オペレーティングシステムが管理情報をメモリに配置する構造を考慮して、前記デバッグ用プログラムが起動している実行ユニットとは異なるデバッグ対象の実行ユニットが利用する記憶領域から必要情報を抽出する処理とをさらにコンピュータに実行させる、請求項２３に記載のプログラム。
32. 前記複数の実行ユニットの中から不具合が発生した実行ユニットを検出し、検出された実行ユニットのデバッグを行うための起動指示を生成する処理をさらにコンピュータに実行させる、請求項２３に記載のプログラム。
33. 前記複数の実行ユニットのいずれかにおいて起動されるデバッグ用プログラム内に構成された実行ユニット間割り込み生成手段が、デバッグ対象の実行ユニットに対して割り込みを発生させる処理と、
    前記複数の実行ユニットの各々において割り込みが発生した場合に該割り込みを処理するために最初に起動されるプログラムである割り込みハンドラ内に構成された情報取得・制御手段が、他の実行ユニットからの割り込みが発生した際に、予め設定されたメモリ内の情報を取得する処理と、
    前記情報取得・制御手段により取得された情報を、割り込みを発生させた実行ユニットに対して送信する処理と、
    デバッグ用プログラムが起動された実行ユニットが、デバッグ対象の実行ユニットからの応答を受信する処理とをさらにコンピュータに実行させる、請求項２３に記載のプログラム。

Images