(57)【要約】【課題】並列に実行されるプログラムの潜在的な不具合を検出することができるデバッグ支援装置およびそのためのプログラムを提供する。【解決手段】デバッグ支援装置は、プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部C0,C1,C2と、前記複数のCPU によって共有される共有資源の模擬部Mと、各CPU模擬部と前記共有資源の模擬部間において発生した所定のイベントを検出するイベントモニタ部C3,C13,C23と、並列実行される前記プログラムのスレッド間の相対的な順序関係の情報を記録するためのベクトルクロック表と、前記相対的な順序関係の情報に基づいて、スレッド間の順序関係が半順序関係となるイベントが発生したか否かを判定し、前記半順序関係であるイベントが発生したときに、前記共有資源に対するキャッシュ操作に関する履歴情報を記録するカスタム部CPとを有する。【選択図】図４
2011203803.tif 000002
【特許請求の範囲】
【請求項１】
プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部と、
前記複数のCPU によって共有される共有資源の模擬部と、
前記各CPU模擬部と前記共有資源の模擬部間において発生した所定のイベントを検出するイベントモニタ部と、
並列実行される前記プログラムのスレッド間の相対的な順序関係の情報を記録するための順序関係記録部と、
前記相対的な順序関係の情報に基づいて、スレッド間の順序関係が半順序関係となるイベントが発生したか否かを判定し、前記半順序関係であるイベントが発生したときに、前記共有資源に対するキャッシュ操作に関する履歴情報を記録する状態判定部と、
を有することを特徴とするデバッグ支援装置。
【請求項２】
前記所定のイベントは、前記各CPU模擬部に設けられたキャッシュメモリ模擬部を介する前記共有資源の模擬部へのアクセスを含み、前記キャッシュ操作は、前記キャッシュメモリ模擬部に対する操作であることを特徴とする請求項１に記載のデバッグ支援装置。
【請求項３】
前記キャッシュ操作に関わるキャッシュライン毎の、キャッシュの状態と、直近の状態及び直近の状態遷移操作を行ったスレッドの前記相対的な順序関係の情報を記録するためのキャッシュライン情報管理表を有し、
前記状態判定部は、前記順序関係記録部における前記相対的な順序関係の情報と前記キャッシュライン情報管理表における前記相対的な順序関係の情報とを比較することによって、前記半順序関係となるイベントが発生したか否かを判定することを特徴とする請求項１に記載のデバッグ支援装置。
【請求項４】
プログラムを並列に実行する複数のCPUの各CPUと前記複数のCPU によって共有される共有資源間において発生した所定のイベントを検出するイベントモニタ部と、
前記各CPUにおいて並列実行された前記プログラムのスレッド間の相対的な順序関係の情報を記録する順序関係記録部と、
前記相対的な順序関係の情報に基づいて、スレッド間の順序関係が半順序関係となるイベントが発生したか否かを判定し、前記半順序関係であるイベントが発生したときに、前記共有資源に対するキャッシュ操作に関する履歴情報を記録する状態判定部と、
を有することを特徴とするデバッグ支援装置。
【請求項５】
プログラムを並列に実行する複数のCPUの各CPUと前記複数のCPU によって共有される共有資源間において発生した所定のイベントを検出するイベントモニタ機能と、
並列実行される前記プログラムのスレッド間の相対的な順序関係の情報を記録する機能と、
前記相対的な順序関係の情報に基づいて、スレッド間の順序関係が完全順序関係ではなく半順序関係となるイベントが発生したか否かを判定する機能と、
前記半順序関係であるイベントが発生したときに、前記共有資源に対するキャッシュ操作に関する履歴情報を記録する機能と、
をコンピュータに実行させるためのデバッグ支援用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバッグ支援装置及びデバッグ支援用プログラムに関し、特に、並列に実行されるプログラムのデバッグ支援装置及びデバッグ支援用プログラムに関する。
【背景技術】
【０００２】
従来より、複数のコアを有するマルチコア・プロセッサシステムが広く利用されている。マルチコア・プロセッサシステムは、システムに含まれる各コアがキャッシュメモリを持つ並列計算機である場合がある。マルチコア・プロセッサシステムでは、値の一貫性(コンシステンシ)は、ハードウエア（以下、HWと略す）もしくはソフトウエア（以下、SWと略す）により保たれる。
【０００３】
特に、SWによりコンシステンシを保つシステムの場合、メモリ空間はページ単位で分割され、各コアは、各処理に関連するページをshared状態あるいはexclusive状態として管理して、各処理を実行する。
【０００４】
例えば、２つのコア１，２が、それぞれ演算部とキャッシュメモリとを有して、バスを介して接続された１つのメインメモリ中のデータを処理する並列計算機の場合を仮定する。メモリ空間はページ単位に分割され、処理に関わるページは、各コアのプログラムの実行時に、shared状態あるいはexclusive 状態にされる。
【０００５】
例えば、ある時、あるページａが、コア間でデータが共有されるためにshared状態にされ、あるページｂは、特定のコアがデータを書き込むためにexclusive状態にされたとする。shared状態のページａは、コア間で共有されるため、どのコアもread可能であるが、どのコアもwriteは不可とされる。
【０００６】
ページａはshared状態なので、コア１およびコア２がページａ中のあるラインから値を読むと、同じ値、例えばｙがreadされる。shared状態では、コア１及びコア２は値をページａにwriteすることは禁止される。これは、例えば、もしコア１がページａのそのラインに、ある値、例えばｚをwriteすると、コア２からはその更新された値が見えないため、古い値ｙがreadされてしまい、コンシステンシが保たれないからである。  
exclusive状態のページｂは、いわゆるownerとなった特定のコアにより占有されるため、その特定のコアだけがread及びwriteが可能とされる。
【０００７】
ページbがコア１によりexclusive状態にされているので、コア1は、ページb中の各ラインに対してreadもwriteも可能である。そして、メインメモリ上の値ｙと、コア1のキャッシュメモリ内の値zは、異なっていても（inconsistent)、問題ない。これは、ページｂのデータをreadするのは、コア1だけであるためである。また、このinconsistentな状態の問題は、コア1がラインbを解放する時にメモリにwrite backすることにより解消される。コア２は、ページbがexclusive状態の間、ページｂ中のデータをreadもwriteもしてはいけない。これは、データをreadすると古い値が読めてしまう可能性があるからである。さらに、間違ってデータをwriteすると、コア1がそのwriteした値を異なる値で上書きしてしまう可能性があるからである。  
各ページは、このような状態に応じてアクセス制限され、また、この状態は、プログラムの実行中に動的に変化する。
【０００８】
このようなマルチコア・プロセッサシステムにおいて実行されるソフトウエアを、コンシステンシも含めてデバッグする技術が種々提案されている。通常、ソフトウエアのデバッグを行う場合に、コア内部の動作を観測するために、デバッグ対象のプログラム中に観測用のコードが追加される。その追加されたコードにより、対象プログラムに基づくコア内部の動作状態の観察を行うことができる。
【０００９】
また、デバッグコントロールユニットを内蔵して、１つのCPUによりそのデバッグコントロールユニットを制御するマルチコアプロセッサが提案されている（特許文献１参照）。また、複数のプロセッサのそれぞれのメモリ領域に対するプログラムのアクセスを観察することのできるデバッグ支援装置も提案されている（特許文献２参照）。
【００１０】
しかし、デバッグ対象のプログラムに観測用のコードが追加されると、追加された分だけ実行コードが増えるため、観測用のコードが追加されていないプログラムが実行された場合と、観測用のコードが追加されたプログラムが実行された場合では、各実行タイミング等が変わってしまうため、デバッグが正確にできないという問題がある。例えば、観測用のコードが追加されていないプログラムが実行された場合には不具合が発生するが、観測用のコードが追加されたプログラムが実行された場合には不具合が発生しない等の問題が生じる場合がある。
【００１１】
特に、マルチコア・プロセッサシステムの場合、デバッグ時には複数のコアに着目し、各コアの挙動を観察し、バグ発見のための解析をしなければならない。
【００１２】
しかし、上記の提案に係る技術によれば、挙動に伴うデータの観察はできるが、バグに関する情報を正確に検出することはできない。さらに、これらの提案では、バグに関する情報を、プログラム開発者等に分かり易く知らしめる方法も特に提案されていない。
【００１３】
一方で、メモリ等の共有資源管理を行なうHWを有しないシステムにおいては、上述したように、プログラム開発者がSW中に資源の占有状態遷移処理の呼び出しコードを対象プログラム中に埋め込むことにより、資源の占有状態管理を行なう必要がある。その資源管理処理の規約違反を検出し、プログラム開発者に提示する手法として、共有メモリのキャッシュコヒーレンス違反検出を対象とした提案もされている（例えば、特許文献３，特許文献４参照）。しかし、この提案では、並列に動作する複数の処理装置から占有状態遷移処理が呼び出される場合の、違反原因の特定が困難である。
【００１４】
さらに、並列に動作する複数の処理装置からの共有資源利用状況を表示する手法としては、タスク遷移状態と資源利用状況を時系列に図示して性能改善に利用する技術の提案もされている（例えば、特許文献５参照）が、規約違反の検出には利用できない。
【００１５】
また、マルチコア・プロセッサシステムにおいては、上述したコンシステンシの問題以外にも、排他制御における、ロックあるいはアンロックの命令に関する性能、デッドロック発生等の問題もある。
【００１６】
従って、このような問題も含めて、バグ等に関する情報を正確に検出する方法、及びそのバグ等に関する情報を、プログラム開発者等に分かり易く知らしめる方法についても、提案されていない。
【００１７】
さらに、複数のスレッドにより実行されるキャッシュ操作APIの実行順が定まっていない場合には、潜在的なキャッシュコヒーレンス違反を検出することはできないという問題がある。例えば、マルチコア・プロセッサシステムにおいて、２つのスレッドＡ，Ｂが、共通のキャッシュラインｂを別々にExclusive状態に遷移させるプログラムを含む場合に、先に実行されたスレッドＡの後に、スレッドＢが実行されるとする。この場合、スレッドＡがそのキャッシュラインｂをExclusive状態からshared状態に戻す前に、スレッドBの実行が開始されると、プログラムの不具合となる。
【００１８】
デバッグはそのプログラムの実行環境は２つのCPUを用いる環境を想定して行われ、デバッグ時には、スレッドＢを実行するCPUが、たまたまスレッドCを実行してスレッドAの実行が終了した後に、スレッドBが実行されれば、デバッグ時に、そのプログラムの不具合は、発見されない。すなわち、そのプログラムは、スレッド間で同期が取れていないため、潜在的な不具合を内包する。
【００１９】
しかし、プログラムの実行環境が４つのCPUを用いる環境に変わると、スレッドCが別のCPUにより実行され、スレッドBの実行開始が早まると、プログラムの実行エラーとなり、その潜在的な不具合が顕在化する。
【００２０】
スレッド間の同期が不適切なことによる潜在的な不具合を検出する手法には、スレッド間の主メモリへのデータアクセスの順序関係について検出するデータレース検出手法がある（例えば、非特許文献１参照）。  
しかし、従来のデータレース検出手法は、キャッシュメモリのデータを考慮していないため、上述したようなキャッシュコヒーレンス違反が発生する潜在的な不具合については、検出できなかった。
【先行技術文献】
【特許文献】
【００２１】
【特許文献１】特開2006-146412号公報
【特許文献２】特開平05-165675号公報
【特許文献３】特表2008-517370号公報
【特許文献４】米国特許公開US2006-0259698 A1号公報
【特許文献５】特開2008-4054号公報
【非特許文献】
【００２２】
【非特許文献１】森達矢、松崎秀則著「細粒度スレッドモデル向けデータレース検出亜リゴリズムの提案」情報処理学会論文誌、2008年Feb,  Vol.49, No.2
【発明の概要】
【発明が解決しようとする課題】
【００２３】
そこで、本発明は、並列に実行されるプログラムの潜在的な不具合を検出することができるデバッグ支援装置およびそのためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２４】
本発明の一態様によれば、プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部と、前記複数のCPU によって共有される共有資源の模擬部と、前記各CPU模擬部と前記共有資源の模擬部間において発生した所定のイベントを検出するイベントモニタ部と、並列実行される前記プログラムのスレッド間の相対的な順序関係の情報を記録するための順序関係記録部と、前記相対的な順序関係の情報に基づいて、スレッド間の順序関係が半順序関係となるイベントが発生したか否かを判定し、前記半順序関係であるイベントが発生したときに、前記共有資源に対するキャッシュ操作に関する履歴情報を記録する状態判定部と、を有することを特徴とするデバッグ支援装置を提供することができる。
【発明の効果】
【００２５】
本発明によれば、並列に実行されるプログラムの潜在的な不具合を検出することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の第１の実施の形態に係わるプログラム開発装置の構成を示す構成図である。
【図２】本発明の第１の実施の形態に係わるシミュレータP2の構成を示す構成図である。
【図３】本発明の第１の実施の形態に係わるPC一覧生成プログラムの処理の流れの例を示すフローチャートである。
【図４】本発明の第１の実施の形態に係わるプログラム開発装置１のデバッグ処理関連の全体の処理の流れを説明するための図である。
【図５】本発明の第１の実施の形態に係わる、イベントモニタ部の演算模擬部の実行状態を監視する処理の流れの例を示すフローチャートである。
【図６】本発明の第１の実施の形態に係わる、イベントモニタ部のリソース間の処理内容を監視する処理の流れの例を示すフローチャートである。
【図７】本発明の第１の実施の形態に係わる状態表の例を示す図である。
【図８】本発明の第１の実施の形態に係わるプロトコル規定表の例を示す図である。
【図９】本発明の第１の実施の形態に係わる判定結果記録表の例を示す図である。
【図１０】本発明の第１の実施の形態に係わるベクトルクロック表の例を示す図である。
【図１１】本発明の第１の実施の形態に係わるキャッシュライン情報管理表の例を示す図である。
【図１２】本発明の第１の実施の形態に係わるプログラムコード（コード１）の例である。
【図１３】本発明の第１の実施の形態に係わる、コード１の実行が開始されたときの、すなわち初期状態における、ベクトルクロック表の状態を示す図である。
【図１４】本発明の第１の実施の形態に係わる、コード１のスレッド１の実行が開始されたときの、すなわち初期状態における、キャッシュライン情報管理表の状態を示す図である。
【図１５】本発明の第１の実施の形態に係わる、コード１の３行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【図１６】本発明の第１の実施の形態に係わる、コード１の５行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【図１７】本発明の第１の実施の形態に係わる、スレッド１の対角要素に「１」が加算された状態を示すベクトルクロック表を示す図である。
【図１８】本発明の第１の実施の形態に係わる、スレッド２の１番目の要素に「１」がコピーすなわち上書きされた状態を示すベクトルクロック表を示す図である。
【図１９】本発明の第１の実施の形態に係わる、コード１の１１行目の関数の実行がされる前のキャッシュライン情報管理表の状態を示す図である。
【図２０】本発明の第１の実施の形態に係わる、コード１の１１行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【図２１】本発明の第１の実施の形態に係わる、正しい同期処理が記述されていないコード例（コード２）を示す図である。
【図２２】本発明の第１の実施の形態に係わる、コード２の１１行目におけるベクトルクロック表の例を示す図である。
【図２３】本発明の第１の実施の形態に係わる、潜在的不具合判定結果記録表１０７の例を示す図である。
【図２４】本発明の第１の実施の形態に係わる、ユーザに示す表示例１としての違反ソース行番号表の表示例を示す図である。
【図２５】本発明の第１の実施の形態に係わる、違反時刻一覧表表示の例を示す図である。
【図２６】本発明の第１の実施の形態に係わる、ソースコード強調表示の例を示す図である。
【図２７】本発明の第１の実施の形態に係わる、違反が検出された際の関数の時系列表示の例を示す図である。
【図２８】本発明の第２の実施の形態に係るプログラム開発装置１Aの構成を示す構成図である。
【図２９】本発明の第２の実施の形態に係る、マルチコアプロセッサ２２において実行されるプログラムの構成を示す図である。
【図３０】本発明の第２の実施の形態に係る、本実施の形態におけるシミュレータP21の構成を説明するための図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照して本発明の実施の形態を説明する。  
（第１の実施の形態）
（構成）
まず図１に基づき、本発明の第１の実施の形態に係わるプログラム開発装置の構成を説明する。図１は、本実施の形態に係わるプログラム開発装置の構成を示す構成図である。  
デバッグ支援装置としてのプログラム開発装置１は、各種ソフトウエアプログラムを実行する中央処理装置（以下、CPUという）２ａを有する本体装置２と、本体装置２と接続され各種ソフトウエアプログラム等を記憶する記憶部３と、本体装置２と接続された表示部４と有して構成されている。なお、図示しないが、ユーザが、各種プログラムを実行させるための指示を与えるための、キーボード、マウス等の入力装置が、本体装置２には接続されている。
【００２８】
記憶部３には、各種ソフトウエアプログラムとして、デバッグ対象プログラムP1と、デバッグ機能付きのシミュレーションプログラム（以下、シミュレータという）P2と、バグ解析表示プログラムP3、プログラムカウンタ（PC）一覧生成プログラムP4が記憶されている。本体装置２のCPU２ａは、記憶部３に記憶されたこれらのプログラムを実行あるいは読み出すことができる。
【００２９】
従って、プログラム開発者（以下、ユーザともいう）は、開発中のプログラムをデバッグあるいはチューニングする場合は、その開発中のプログラムを、記憶部３に記憶させ、開発中のプログラムを、デバッグ対象プログラムP1として指定して、シミュレータP2を実行してデバッグ等することができる。
【００３０】
そして、バグ解析表示プログラムP3により、デバッグの結果は、表示部４の画面上に分かり易く表示させることができる。
【００３１】
開発中のプログラムは、並列計算機であるマルチコア・プロセッサシステム上で実行されるプログラムである。そのマルチコア・プロセッサシステムは、ハードウエアによるコンシステンシを一致させるための調停機構を有していない。プログラム開発者は、プログラムの中に共有資源を占有状態あるいは非占有状態に遷移させる処理の呼び出しを埋め込むことにより共有資源の占有状態の管理を行う必要がある。以下、例として、開発中のプログラムは、３つのコアプロセッサ上で、実行されるプログラムであるとして説明する。そして、シミュレータP2は、マルチコア・プロセッサシステムはそれぞれがキャッシュメモリを含む複数のコアプロセッサ（ここでは２つのコアプロセッサ）と、１つのメインメモリを有しているものとして、デバッグのためのシミュレーションを実行するものとして説明する。そして、共有メモリであるメインメモリ上の一部の領域を、コアプロセッサである各処理装置内の非共有のキャッシュメモリにキャッシュする場合、キャッシュのコヒーレンスを保証する必要がある。
【００３２】
（シミュレータの構成）
次に、シミュレータP2の構造について説明する。図２は、シミュレータP2の構成を示す構成図である。  
シミュレータP2は、３つのコアプロセッサ（以下、単にコアともいう）を模擬したコアプロセッサ模擬部（以下、コア模擬部という）C0,C1,C2と、共有メモリであるメインメモリを模擬したメモリ模擬部Mを含む。コア模擬部C0,C1,C2は、プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部であり、それぞれ、演算模擬部とキャッシュ模擬部とを含む。コア模擬部C0は、演算模擬部C01とキャッシュ模擬部C02とを含み、コア模擬部C1は、演算模擬部C11とキャッシュ模擬部C12とを含み、コア模擬部C2は、演算模擬部C21とキャッシュ模擬部C22とを含む。
【００３３】
シミュレータP2はさらに、コア模擬部C0用のイベントモニタ部C03と、コア模擬部C1用のイベントモニタ部C13と、コア模擬部C2用のイベントモニタ部C23と、コア模擬部C0用の内部状態情報収集部C4と、コア模擬部C1用の内部状態情報収集部C14と、コア模擬部C2用の内部状態情報収集部C24と、イベントコレクタ部ECと、カスタム部CPと、バス模擬部CBとを含む。
【００３４】
コア模擬部C0〜C2は、デバッグ対象プログラムP1が実行されるマルチコア・プロセッサシステム（以下、対象プロセッサという）における３つのコアプロセッサに対応する。  
演算模擬部C01〜,C21は、それぞれ対象プロセッサのコアプロセッサの演算部を模擬する処理部である。演算模擬部C01〜C21は、各演算部の種々の演算機能を実現する処理部である。
【００３５】
キャッシュ模擬部C02〜C22は、それぞれ対象プロセッサにおけるコアプロセッサのキャッシュメモリ、すなわち非共有キャッシュメモリを模擬する処理部である。  
メモリ模擬部Mは、メインメモリを模擬する処理部である。すなわち、メモリ模擬部Mは、複数のCPU によって共有される共有資源の模擬部である。  
バス模擬部CBは、対象プロセッサの各コアプロセッサとメインメモリを接続するバスを模擬する処理部である。
【００３６】
イベントモニタ部C03〜C23は、それぞれコア模擬部C0〜C2の内部で発生する各イベントを収集しイベントコレクタ部ECに伝達する機能を実現する処理部である。例えば、イベントモニタ部C03〜C23は、各CPU模擬部とメモリ模擬部M間において発生した所定のイベントを検出する。言い換えると、各イベントモニタ部は、模擬部間のデータを監視する処理部である。具体的には、各イベントモニタ部は、対応する演算模擬部とキャッシュ模擬部間、キャッシュ模擬部とメモリ模擬部間及び演算模擬部とメモリ模擬部間のデータのやりとりを監視する。例えば、各イベントモニタ部は、各コア模擬部に設けられたキャッシュ模擬部を介するメモリ模擬部Mへのアクセスを含むイベントを検出する。
【００３７】
イベントとしては、キャッシュアクセス、キャッシュリフィル要求、キャッシュ・ライトバック要求、占有状態あるいは非占有状態への遷移要求、スレッド間の同期信号の送受信などがある。また、イベントモニタ部C03〜C23は、演算部のポインタが事前に登録しておいたプログラムカウンタ(PC)の値になったときに、イベントとして通知する機能も有する。例えば、メモリ領域の状態を変更するような関数の先頭を事前に登録しておくことにより、その関数の実行をイベントの発生として検出することができる。
【００３８】
例えば、図２に示すように、コア模擬部C2における演算模擬部C21からキャッシュ模擬部C22にキャッシュアクセスｃａがあれば、そのアクセスが監視される。さらに、イベントモニタ部C23は、キャッシュ模擬部C22とメモリ模擬部M間のキャッシュリフィル要求ｃｒ、あるいはキャッシュ・ライトバック要求ｗｂ等のイベントを監視する。さらに、イベントモニタ部C23は、演算模擬部C21からメモリ模擬部Mへのキャッシュをスルーした読み出し要求ｔａ等も監視する。そして、イベントモニタ部C23は、スレッド間の同期動作も監視する。
【００３９】
イベントの監視は、シミュレータP2の実行中におけるメモリ空間上の所定のアドレスへのアクセス等の有無を監視することにより行われる。たとえば、各イベントモニタ部は、所定のアドレスのデータの読み出しあるいは書き込みがあれば、所定のイベントが発生したと判定し、そのイベント情報をイベントコレクタ部ECに伝達することができる。なお、イベントの監視は、所定の操作命令の実行の有無によって行うようにしてもよい。
【００４０】
イベントコレクタ部ECは、各イベントモニタ部から伝達された情報およびバス模擬部CBからの情報を収集し、所定のイベントが発生すると、その発生したイベント情報をカスタム部CPに伝達し、カスタム部CPを呼び出す。呼び出されたカスタム部CPは、相対的な順序関係の情報に基づいて、スレッド間の順序関係が完全順序関係ではなく半順序関係となるイベントが発生したか否かを判定し、半順序関係であるイベントが発生したときに、共有資源に対するキャッシュ操作に関する履歴情報を記録する状態判定部を構成する。
【００４１】
カスタム部CPは、受信したイベント情報に基づいて、所定の条件に合致しているか等の所定のチェックを行うために、イベントコレクタ部ECから呼び出され、その所定のチェックを行う機能を実現する処理部である。このカスタム部CPのチェック内容すなわち判定の条件は、ユーザが目的あるいはチェックしたい内容に応じて、設定あるいは変更してカスタマイズできるようになっている。この設定された条件等は、判定条件情報としてプロトコル規定表に記憶され、あるいはカスタム部CPの判定プログラムに記述される。
【００４２】
上述した例であれば、あるページがexclusive状態に既にされているにも拘わらず、重ねて同じページにexclusive状態にするコマンドが再度発行された場合には、違反設定があったとする判定の条件が予め設定されているとする。その場合、カスタム部CPはexclusive状態にするイベントが発生すると、その条件が満たされるか否かのチェックを行う。再度exclusive状態にするコマンドが発生すると、カスタム部CPは違反発生を判定することになる。よって、ユーザは、カスタム部CPに対して、チェックしたい内容を自由に設定することができる。
【００４３】
さらに、例えば、あるスレッド１が所定の同期信号を他のスレッド２に送信し、スレッド２が同期信号を受信してから所定の処理を実行しなければならないときに、スレッド２が同期信号の受信を待たずにその所定の処理を実行している場合には、潜在的なコヒーレンス違反があったとする判定条件、ルール等が、判定条件情報として予め設定されているとする。すなわち、その判定条件は、スレッド間の順序関係が半順序関係である場合に、各スレッドで発生するイベントの実行順序が変化し得ることによる潜在的な違反が存在するとする条件である。その場合、カスタム部CPは、同期信号に関するイベントが発生すると、その条件等が満たされるか否かのチェックを行う。よって、ユーザは、カスタム部CPに対して、チェックしたい条件等の内容を自由に設定あるいは記述することができる。
【００４４】
内部状態情報収集部C04,C14,C24は、対応するコアプロセッサ内部のレジスタやキャッシュメモリなどの値を読み出す機能を実現する処理部である。内部状態情報収集部C04〜C24は、それぞれカスタム部CPからの要求に応じて、対応するコアの各模擬部及びメモリ模擬部Mのデータを収集する。収集されるデータには、処理対象のデータ等だけでなく、サイクル数の情報等のデータも含まれる。
【００４５】
（動作）
次に、プログラム開発装置１のデバッグ動作を説明する。  
ユーザすなわちプログラム開発者は、開発したあるいは開発中のプログラムをデバッグするために、シミュレータP2とバグ解析表示プログラムP3を実行させる。シミュレータP2は、デバッグ対象プログラムP1を、シミュレータP2において実行し、バグ解析表示プログラムP3は、シミュレータP2の実行結果に基づいて、発生したバグに関して、バグを解析するのに分かり易い表示を、表示部４の画面上に表示させることができる。
【００４６】
（プログラムカウンタ一覧の作成と登録）
このようなデバッグ処理が、プログラム開発装置１において実行されるが、前処理として、PC一覧生成プログラムP4により、プログラムカウンタ一覧（以下、PC一覧ともいう）が生成される。PC一覧は、イベントとプログラムカウンタ値の対応関係を示すデータである。  
デバッグ対象プログラムP1は、ソースプログラムであり、コンパイルされてオブジェクトプログラムに変換される。その変換されたオブジェクトプログラムが、シミュレータP2上で実行される。
【００４７】
従って、オブジェクトプログラムが生成されると、そのオブジェクトプログラムからPC一覧のデータが予め作成され、各イベントモニタ部C03〜C23に登録される。そして、そのPC一覧に基づいて、各イベントモニタ部C03〜C23は、所定のイベントが発生したか否かの判定を行う。同期信号の送受信も、それぞれ一つのイベントとして、PC一覧に含まれる。
【００４８】
図３は、予め生成されて登録されるPC一覧を生成し、イベントモニタ部に登録するためのPC一覧生成プログラムの処理の流れの例を示すフローチャートである。図１に示すように、このPC一覧生成プログラムP4も記憶部３に記憶され、本体装置２のCPU２ａによって実行される。
【００４９】
また、どのようなイベントを監視するかがユーザにより、事前に決められている。よって、監視すべきイベント（以下、監視対象イベントともいう）の名前は、メモリアクセス情報として、所定のライブラリ（以下、メモリアクセスライブラリという）に予め登録される。ユーザは、このメモリアクセスライブラリの名前一覧の内容を変更することにより、監視対象イベントを自由に設定し、変更することができる。
【００５０】
図３に示すように、このメモリアクセスライブラリの名前一覧１０１のデータが設定された後、本体装置２のCPU２ａは、その名前一覧１０１を基に、対応するオブジェクトプログラムについてのPC一覧１０２を作成する（S1）。
【００５１】
CPU２ａは、作成されたPC一覧のデータを、対応する各イベントモニタ部C03〜C23に登録する（S2）。PC一覧のデータは、デバッグ対象プログラムP1中の監視すべきコードに対応するオブジェクトコードのプログラムカウンタの値（以下、PC値という）のデータである。
【００５２】
例えば、「allocate_shared」のコマンドが監視対象イベントの場合、「allocate_shared」のコードに対応する、オブジェクトコードのPC値が、イベントの内容あるいは命令と共に、PC一覧に登録される。
【００５３】
すなわち、各イベントモニタ部C03〜C23には、対応するコアに関して、監視対象イベントに対応するオブジェクトコードのPC値が登録される。
【００５４】
また、ユーザは、上述したチェックしたいイベントに応じた条件等も、プロトコル規定表として予め設定し登録する。以下、プログラム開発装置１のデバッグ処理関連の全体の処理の流れと共に、各処理部の処理の内容を説明する。
【００５５】
（プロトコル違反の検出処理）
図４は、プログラム開発装置１のデバッグ処理関連の全体の処理の流れを説明するための図である。  
図４に示すように、デバッグ対象プログラムP1が、シミュレータP2により実行される。その実行処理１１では、PC一覧のデータを用いて、イベントモニタ部C03〜C23が所定のイベントの発生を監視し、イベントコレクタ部ECは検出された所定のイベント情報を、実行記録データ（表１）、ベクトルクロック表（表２）及びキャッシュライン情報管理表（表３）に記憶する。実行記録データ、ベクトルクロック表及びキャッシュライン情報管理表は、記憶部３の一部の記憶領域１０３に設けられている。実行処理１１は、イベントモニタ部C03〜C23、イベントコレクタ部EC及びカスタム部CPによって実行される。
【００５６】
まず、実行処理１１におけるイベントモニタ部C03〜C23の処理の内容を説明する。  
（イベントモニタ部の処理）
図５は、イベントモニタ部の演算模擬部の実行状態を監視する処理の流れの例を示すフローチャートである。  
デバッグ対象プログラムP1が実行されると、イベントモニタ部C03〜C23は、演算模擬部C01〜C21において実行中のプログラムのPC値を監視する（S11）。監視しているPC値が、PC一覧１０２に予め登録されているいずれかのPC値と一致するか否かが、判定される（S12）。
【００５７】
不一致の場合（S12、NO）は、処理は何もせずにステップS11に戻る。  
一致した場合（S12、YES）は、ユーザが監視したいとして設定したイベントが発生したことを意味するので、イベントモニタ部は発生したイベントの情報をイベントコレクタ部ECに伝達する（S13）。イベント情報は、イベントを発生したコアプロセッサ（すなわち処理装置）、PC値及びイベントの内容の情報を含む。
【００５８】
以上のように、演算模擬部に対応するコアプロセッサのCPUが、キャッシュ模擬部に対応するキャッシュメモリあるいはメモリ模擬部に対応するメインメモリに対して、予め設定されたアクセスを行ったり、スレッド間の同期処理等を行うと、イベントモニタ部は、そのイベントの情報をイベントコレクタ部ECへ伝達する。
【００５９】
さらに、イベントモニタ部C03〜C23は、キャッシュ模擬部に対応するキャッシュメモリとメモリ模擬部に対応するメインメモリとの間で、発生した通信も監視する。具体的には、図６に示すような処理が行われる。通信は、例えば、キャッシュリフィルがあった場合に発生する。  
図６は、イベントモニタ部のリソース間の処理内容を監視する処理の流れの例を示すフローチャートである。
【００６０】
デバッグ対象プログラムが実行されると、イベントモニタ部C03〜C23は、キャッシュ模擬部とメモリ模擬部との間で、発生した通信を監視する（S21）。  
その通信が有るか否かを監視し（S22）、通信がなければ、すなわち発生しなければ（S22、NO）、処理は何もせずS21に戻る。
【００６１】
通信が有れば、すなわち発生したときは（S22、YES）、その通信のイベントをイベントコレクタ部ECに伝達する（S23）。  
以上のように、実行処理１１では、キャッシュ模擬部に対応するキャッシュメモリとメモリ模擬部に対応するメインメモリとの間で通信があれば、そのイベントの情報をイベントコレクタ部ECへ伝達する。
【００６２】
実行処理１１では、イベントコレクタ部ECは、各イベントモニタ部からのイベントの情報を受信すると、カスタム部CPに受信したイベント情報を伝達する。
【００６３】
（カスタム部の処理）
カスタム部CPは、判定処理を行うプログラムである。  
（各操作の有効性の検証）
まず、カスタム部CPは、各命令すなわち各操作が有効であるか否かを検証するためにイベント情報を受信すると、内部状態情報収集部C04〜C24を介して、イベント毎に予め決められたデータを収集し、イベント情報を実行記録表に記録する。すなわち、状態判定部としてのカスタム部CPは、そのイベントに対応して予め決められた情報を、内部状態情報収集部C04〜C24を介して収集して、受信したイベント情報と共に、イベントのプロファイルとして、実行記録表に記録する。例えば、あるイベントについては、引数１が所定のレジスタに登録されているので、そのレジスタのデータを収集するように、カスタム部CPでは、内部状態情報収集部を介して収集すべきデータが予め決められている。
【００６４】
（実行記録表）
実行記録表に記録される実行記録データとしてのイベント情報は、処理装置、時刻、PC値、内容、１以上の引数、戻り値の各項目データを含む。カスタム部CPは、発生したイベント毎にそのイベントの情報を、内部状態収集部を介して収集したデータと共に記録する。
【００６５】
すなわち、実行記録表には、各CPU模擬部における並列処理単位である関数、スレッド等の生成、開始及び終了、また、メモリの割り当て、状態遷移、読み出し、書き込み及び解放のデータが含まれる。
【００６６】
カスタム部CPは、イベント情報を実行処理１１の実行記録データとして、実行記録表に記録していく。  
カスタム部CPは、実行記録表のイベント情報に基づいて、図７の状態表の状態データを作成する。図７は、状態表の例を示す図である。  
（状態表）
図７の状態表１０４は、メモリ領域の領域先頭、領域末端、割り当て時刻（サイクル数）、割り当てPC、割り当て処理装置、最終状態遷移処理時刻、最終状態遷移処理PC、最終状態遷移処理装置、状態の各項目を含む。あるメモリ領域がshared状態にされるとき、そのshared状態にするイベントが発生する。そして、そのshared状態が解除されるときも、その解除のイベントが発生する。そして、その解除のイベントに応じて、状態表１０４から、sharedにされたメモリ領域が発生したことを示す状態データが削除される。
【００６７】
従って、カスタム部CPは、イベントの発生に応じて、メモリ領域の状態の遷移を状態表１０４に書き込んでいく。そして、カスタム部CPは、状態遷移操作に応じて、実行記録表を先頭から読み出して、遷移された状態が消滅すれば、状態表１０４からその状態データは削除される。よって、状態表の内容、すなわち状態データは、デバッグ対象プログラムP1の実行に伴って、発生しては消滅することを繰り返すように変化する。
【００６８】
図７の１行目には、shared状態にされたメモリ領域について、上述した各項目のデータが、１つの状態データとして記憶されていることを示している。  
すなわち、状態表１０４は、コアプロセッサによるリソースに対する状態遷移操作に従って更新され、遷移した状態が無くなれば、その状態データは状態表１０４から削除される。
【００６９】
また、プログラム中のある命令の実行がバグになるのは、上述した例であれば、shared状態のメモリ領域にデータを書き込みするような場合である。そのような違反命令の実行の判断基準が予め規定されていて、表データとして記憶部３に記憶されている。
【００７０】
（プロトコル規定表）
図８は、その表データ（以下、プロトコル規定表という）の例を示す図である。プロトコル規定表１０５は操作毎に、メモリ領域の状態に応じて、メモリアクセスプロトコルの違反であるか否かを示す表データである。プロトコル規定表１０５には、各命令すなわち各操作について、有効か無効（違反）か、メモリ領域がexclusive状態の場合、shared状態の場合の各項目を判定基準データとして含んでいる。
【００７１】
なお、ここでは、違反の判定基準データは表形式のデータであるが、表形式のデータでなくてもよい。  
図４のプロトコル違反判定処理１２では、カスタム部CPが、イベント情報を受信すると、プロトコル規定表１０５を参照して、実行記録表と状態表１０４のデータに基づいて、プロトコル違反の判定を行う。  
違反と判定されると、カスタム部CPは、判定結果記録表１０６にそのプロトコル違反のデータを記憶する。
【００７２】
（判定結果記録表）
図９は、判定結果記録表の例を示す図である。判定結果記録表１０６は、メモリアクセスプロトコル違反が有りと判定されたときにおける、メモリ領域の領域先頭、領域末端、割り当て時刻（サイクル数）、割り当てPC、割り当て処理装置、最終状態遷移処理時刻、最終状態遷移処理PC、最終状態遷移処理装置、状態、違反遷移処理時刻、違反遷移処理ＰＣ及び違反遷移処理装置の各項目を含む。
【００７３】
判定結果記録表１０６は、違反があった時における、状態表１０４のデータ、さらに違反遷移処理時刻、違反遷移処理PC及び違反遷移処理装置のデータが、カスタム部CPによって、違反のプロファイルとして記録される。よって、判定結果記録表１０６には、繰り返し発生した違反も全て記録されることになる。すなわち、カスタム部CPは、イベントが発生したときに所定の条件が合致すると、共有資源としてのメインメモリの状態に関する情報を履歴情報として判定結果記録表１０６に記録する。  
状態表１０４は、状態の遷移に伴って、記憶されるデータは発生し消滅する表であるが、判定結果記録表１０６は、カスタム部CPが更新前の状態と状態遷移操作が、プロトコル規定表１０５の条件を満たすか否かを判定し、違反があるとされたデータを追加していく表である。
【００７４】
（共有資源に対する排他制御における潜在的な不具合の有無の検証）
さらに、カスタム部CPは、共有資源に対する排他制御における潜在的な不具合の有無を検証するために、イベント情報を受信すると、内部状態情報収集部C04〜C24を介してイベント毎に予め決められたデータを収集し、所定のイベント情報をベクトルクロック表とキャッシュライン情報管理表に記録する処理を行う。すなわち、カスタム部CPは、イベント情報を受信すると、そのイベントに対応して予め決められたスレッド間の同期処理に関する情報を内部状態情報収集部C04〜C24を介して収集して、受信したイベント情報と共に、イベントのプロファイルとしてベクトルクロック表とキャッシュライン情報管理表に記録する。
【００７５】
そして、カスタム部CPは、あるキャッシュラインの状態に対して状態遷移操作が行われたときに、共有資源に対する排他制御における潜在的な不具合を判定するための判定基準を有している。その判定基準は、カスタム部CPのプログラム中にルールとして記述されていてもよいし、参照可能な表に含まれるようにしてもよい。
【００７６】
（ベクトルクロック表）
図１０は、ベクトルクロック表の例を示す図である。順序関係記録部であるベクトルクロック表は、並列実行されるプログラムのスレッド間の相対的な順序関係を示す情報を記録するための配列表である。ベクトルクロック表の行と列は、デバッグ対象プログラムP1の実行中に発生したスレッドの識別番号である。
【００７７】
スレッド間の同期処理があったことがイベントとして検出されると、カスタム部CPは、スレッド間の同期処理における順序関係を示す情報を、順序関係記録部であるベクトルクロック表に記録する。  
ここでは、同期処理に関係する処理が実行されたときに、インクリメントされるソフトウエアカウンタ等の値が、順序関係を示す情報としてベクトルクロック表に記録されて判定処理に用いられる。よって、そのカウンタのカウント値が、デバッグ対象プログラムP1の実行中の同期処理の相対的な時刻に対応し、処理の時間の前後を示す。
【００７８】
例えば、ある時刻において、第１のスレッドが第２のスレッドに対して同期処理に関する処理として同期信号の送信を実行すると、カスタム部CPはそのイベントの発生したときの第１のスレッドの対角要素のカウンタ値をインクリメントする。その後、第２のスレッドが第１のスレッドからの同期信号を受信すると、カスタム部CPは、第２のスレッドの第１のスレッドに対応する要素に、第１のスレッドの対角要素のカウンタ値をコピーする。
【００７９】
具体的には、ある時刻において、ベクトルクロック表が、図１０に示す状態にあったとする。図１０の例では、スレッド０の対角要素の値は「３」で、スレッド７のスレッド０に対する要素の値も「３」である。カスタム部CPは、スレッド０がスレッド７に対する同期信号の送信処理を実行したことを検出すると、そのときのカウンタ値が例えば「３」であれば、カウンタ値をインクリメントしてスレッド０の対角要素に「４」を書き込む。さらに、その後、スレッド７がスレッド０からの同期信号を受信して同期待ちの状態がなくなると、すなわち、スレッド０からの同期信号の待ち処理の実行が検出されると、カスタム部CPは、スレッド７のスレッド０に対応する要素に、スレッド０の対角要素に書き込んだ「４」をコピーして上書きする。  
以上のように、ベクトルクロック表は、スレッド間の同期処理における相対的な順序関係が記憶される。
【００８０】
（キャッシュライン情報管理表）
図１１は、キャッシュライン情報管理表の例を示す図である。キャッシュライン情報管理表は、キャッシュライン毎のキャッシュの状態と、直近の状態と、直近の状態遷移操作を行ったスレッドのベクトルクロックを記録するための表である。キャッシュライン情報管理表は、キャッシュラインのアドレス、状態、１つ前の状態、直近のキャッシュ操作、直近のキャッシュ操作のプログラムカウンタ値、直近のキャッシュ操作のスレッド番号、直近のキャッシュ操作のスレッドのベクトルクロックの対角要素、直近のキャッシュ操作のコア番号及び直近のキャッシュ操作の実クロックの各項目を含む。
【００８１】
キャッシュライン情報管理表の行は、イベント毎のキャッシュラインについての上述した各項目の情報を含む。以下、各項目を、図１１の１行目の情報の例を用いて説明する。  
「アドレス」は、キャッシュラインのアドレス、すなわちメインメモリのアドレスである。図１１では、アドレスは、「0x800000」である。
【００８２】
「状態」は、そのキャッシュラインの状態である。図１１では、「Shared」である。  
「１つ前の状態」は、「状態」の前の状態である。図１１では、「Invalid」である。すなわち、「Shared」の前は、「Invalid」であったことが示されている。  
「直近のキャッシュ操作」は、「１つ前の状態」から現在の「状態」に変化させた操作である。図１１では、「Invalid」から「Shared」の状態に変化した操作が、「alloc_shared」であったことが示されている。
【００８３】
「直近のキャッシュ操作のPC」は、直近のキャッシュ操作のプログラムカウンタ値である。図１１では、「alloc_shared」の操作のPC値は、「0X100000」であったことが示されている。  
「直近のキャッシュ操作のスレッド番号」は、直近のキャッシュ操作を行ったスレッド番号である。図１１では、スレッド０が「alloc_shared」を実行したことを示している。
【００８４】
「直近のキャッシュ操作のスレッドのベクトルクロックの対角要素」は、直近のキャッシュ操作を行ったスレッドのベクトルクロックの対角要素の値である。そのスレッドが直近キャッシュ操作を行ったときの対角要素の値が、図１０のベクトルクロック表を参照して記録される。図１１では、スレッド０の対角要素の値が「０」であったことが示されている。
【００８５】
「直近のキャッシュ操作のコア番号」は、直近のキャッシュ操作を実行したコアの番号である。図１１では、「alloc_shared」を実行したコアは、コア０であったことが示されている。  
「直近のキャッシュ操作の実クロック」は、直近のキャッシュ操作が実行されたときのクロックである。図１１では、その実クロックは、「23545」であったことが示されている。
【００８６】
従って、カスタム部CPは、同期処理に関する処理のイベント情報を受信すると、そのイベントに対応して予め決められた情報を内部状態情報収集部C04〜C24を介して収集し、イベントのプロファイルとして、受信したイベント情報と共にベクトルクロック表とキャッシュライン情報管理表に記録する。
【００８７】
（プログラム例を用いたバグの検出例）
図１２は、２つのスレッドにより同じキャッシュラインに対して操作が行われるプログラムコード（以下、単にコードという）の例である。図１２のコードが実行されていく過程におけるベクトルクロック表とキャッシュライン情報管理表の状態と共に説明する。
【００８８】
（同期処理の正しい例）
まず、同期処理が正しく記述されている、間違い（bug）の無いコード例から説明する。図１２のコードは、正しい同期処理が記述されているコード例を示す図である。図１２において、左側には行番号が示されている。
【００８９】
図１２のコード１は、１５行目から始まる部分が親のプログラムであるスレッド０のコード部を含む。スレッド０は、スレッド１を実行してからスレッド２を実行するように記述されている。２つのスレッド１、２により、同じキャッシュラインに対して操作が行われる。コード１は、スレッド０において所定のメモリ領域を確保して、その領域を用いてスレッド１と２が実行されるプログラムである。スレッド１はコア１上で実行され、スレッド２はコア２上で実行される例である。
【００９０】
スレッド１は１行目から記述されている部分であり、スレッド２は８行目から記述されている部分である。  
具体的には、スレッド１は、３行目においてAPI関数「translate_to_exclusive」を利用してスレッド０により確保されたキャッシュラインを「exclusive」の状態にし、４行目において特定のデータ（図１２では「５」）をそのキャッシュラインに書き込み、５行目においてキャッシュラインを「shared」の状態に戻し、６行目において所定の同期信号をスレッド１に送信する、という処理を実行する。
【００９１】
スレッド２は、１０行目において所定の同期信号の受信を待ち、１１行目においてスレッド０により確保されたキャッシュラインを「exclusive」の状態にし、１２行目において特定のデータ（図１２では「３」）をそのキャッシュラインに書き込み、１３行目においてキャッシュラインを「shared」の状態に戻す、という処理を実行する。
【００９２】
次に、コード１の処理におけるイベントモニタ部、イベントコレクタ部、カスタム部の動作を説明する。  
スレッド１は、コア１において実行される。コア１は、３行目において所定のAPI関数「translate_to_exclusive」を利用してshared状態のメモリをexclusive状態に変更するが、この関数のPC値は事前にイベントモニタ部C13に登録されているので、その関数の呼び出しのイベントはイベントモニタ部C13によって検出される。  
イベントモニタ部C13は、検出したこのイベントの情報をイベントコレクタ部ECに送信する。イベントコレクタ部ECは、受信したイベントの情報をカスタム部CPに通知する。
【００９３】
カスタム部CPはイベントの情報を受信すると、内部状態情報収集部C14を経由して、演算模擬部C11等の情報を収集する。カスタム部CPは、内部状態情報収集部C14から演算模擬部C11等に対応するレジスタやメモリの情報を取得することができるので、関数「translate_to_exclusive」についての所定の情報として、引数（例えばaddr、size）の値、および戻り値等の情報を得ることができる。つまり、カスタム部CPは、メモリ領域をexclusive状態にするイベントを検出することができ、取得した情報とそのイベントを発生させたスレッドの現在のベクトルクロックの値を元に、キャッシュライン情報管理表を更新する。
【００９４】
図１３は、コード１の実行が開始されたときの、すなわち初期状態におけるベクトルクロック表の状態を示す図である。図１４は、コード１のスレッド１の実行が開始されたときの、すなわち初期状態におけるキャッシュライン情報管理表の状態を示す図である。図１５は、コード１の３行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【００９５】
図１４に示すように、スレッド１の実行の開始前に、スレッド０がコア０により「0x100000」のPC値の「alloc_shared」を実行して、アドレス「0x800000」は「Invalid」から「Shared」の状態に変更されている。そのスレッド０のベクトルクロック表の対角要素は「１」で、その操作時、実クロックが「23545」であったことも示されている。
【００９６】
カスタム部CPは、コード１の３行目の関数が実行された結果として、キャッシュライン情報管理表を図１４から図１５の状態に更新する。  
コード１の３行目の関数の実行が終了すると、カスタム部CPは、図１５に示すように、キャッシュライン情報管理表を更新する。キャッシュライン情報管理表は、スレッド１がコア１により「0x090000」のPC値の「translate_to_exclusive」を実行して、アドレス「0x800000」は「Shared」から「Exclusive」の状態に変更されたことを示している。このとき、そのスレッド１のベクトルクロック表の対角要素は「０」（図１３）であるので、その値「０」が「直近のキャッシュ操作のスレッドのベクトルクロックの対角要素」の項目にコピーされている。また、その操作は、実クロックが「25153」であったことも示されている。
【００９７】
コード１の５行目において、関数「translate_to_shared」が実行される。その関数の実行も、イベントとして検出される。その検出の結果、カスタム部CPは、キャッシュライン情報管理表を図１６の状態に更新する。図１６は、コード１の５行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【００９８】
コード１の６行目において、コア１は、スレッド２に対して同期信号を送信する関数を実行する。この信号は、同期待ちの状態からの復帰を指示する復帰指示信号である。この関数のPC値も事前にイベントモニタ部C13に登録されているので、イベントモニタ部C13は、その関数の呼び出しのイベントを検出する。
【００９９】
イベントモニタ部C13はそのイベントの情報をイベントコレクタ部ECに送信し、イベントコレクタ部ECはその情報をカスタム部CPに通知する。  
カスタム部CPは、そのイベントの情報を受信すると、内部状態情報収集部C14を経由して、演算模擬部C11等の情報を収集する。カスタム部CPは、内部状態情報収集部C14から演算模擬部C11等に対応するレジスタやメモリの情報を取得することができるので、関数「send_signal」の引数（例えばスレッドの識別子）の値を得ることができる。
【０１００】
そして、カスタム部CPは、取得した情報を元に、ベクトルクロック表におけるスレッド１の対角要素の要素に「１」を加算する。図１７は、スレッド１の対角要素に「１」が加算された状態を示すベクトルクロック表を示す図である。
【０１０１】
コード１の１０行目において同期待ちの関数が実行されて、コア２は、同期待ち状態に入る。  
コア２は、コア1上でスレッド１が関数「send_signal」を実行して同期信号を受信すると、同期待ちの状態から復帰する。  
スレッド２の同期待ちの関数「wait_until_receive_signal」のPCも事前にイベントモニタ部C23に登録されているので、イベントモニタ部C23はその関数の呼び出しのイベントを検出する。イベントモニタ部C23はそのイベントの情報をイベントコレクタ部ECに送信し、イベントコレクタ部ECはその情報をカスタム部CPに通知する。
【０１０２】
カスタム部CPは、そのイベントの情報を受信すると、コア２は同期信号の受信待ちの状態から復帰したことになり、内部状態情報収集部C24を経由して演算模擬部C21等の情報を収集する。スレッド１が同期信号を送信したので、カスタム部CPは、スレッド２の１番目の要素（すなわちスレッド１に対応する要素）を、同期信号を送信した時点におけるスレッド１のベクトルクロックの１番目の要素（すなわち対角要素）の値で上書きする。図１8は、スレッド２の１番目の要素に「１」がコピーすなわち上書きされた状態を示すベクトルクロック表を示す図である。
【０１０３】
コード１の１１行目において、コア２は、関数「translate_to_exclusive」を実行して、shared状態のメモリ領域をexclusiveの状態に変更する。この関数のPCも事前にイベントモニタに登録されているので、イベントモニタ部C23はその関数の呼び出しのイベントを検出する。  
イベントモニタ部C23はそのイベントの情報をイベントコレクタ部ECに送信し、イベントコレクタ部ECはその情報をカスタム部CPに通知する。
【０１０４】
カスタム部CPは、イベントの情報を受信すると、内部状態情報収集部C24を経由して演算模擬部C21等の情報を収集する。カスタム部CPは、内部状態情報収集部C14から演算模擬部C11等に対応するレジスタやメモリの情報を取得することができるので、関数「translate_to_exclusive」の引数（例えばaddr、size）の値、および戻り値を得ることができる。このとき、カスタム部CPは、キャッシュライン情報管理表の対応するアドレスの情報を参照する。
【０１０５】
図１９は、コード１の１１行目の関数の実行がされる前のキャッシュライン情報管理表の状態を示す図である。図２０は、コード１の１１行目の関数の実行が終了したときのキャッシュライン情報管理表の状態を示す図である。
【０１０６】
なお、カスタム部CPは、各操作の有効性の検証を行っているので、例えば、３，５，１１行目の関数の実行が許されているものであるか否かを判定する。１１行目では、その関数「translate_to_shared」は、メモリ領域を「exclusive」の状態から「shared」の状態に変更する関数であるので、許可されているものであると判定される。
【０１０７】
さらに、カスタム部CPは、共有資源に対する排他制御における潜在的な不具合の有無の検証を行っているので、関数「translate_to_exclusive」の操作が直近のキャッシュ操作と実行順序が入れ替わる可能性があるかを判定する。この判定は、キャッシュライン情報管理表中の「直近のキャッシュ操作のスレッドのベクトルクロックの対角要素」の値と、ベクトルクロック表における状態遷移操作を行ったスレッドのベクトルクロックの値の比較を行うことによって行われる。
【０１０８】
具体的には、図１９のキャッシュライン情報管理表において、直近のキャッシュ操作のスレッド１のベクトルクロックの１番目の対角要素は「０」である。一方、図１８のベクトルクロック表において、スレッド２のベクトルクロックの1番目の要素は、同期待ちの処理が実行されたときに「１」で上書きされている。すなわち、図１８のベクトルクロック表におけるその「１」は、図１９のキャッシュライン情報管理表における「直近のキャッシュ操作のスレッドのベクトルクロックの対角要素」の「０」より大きい。よって、このベクトルクロックの値の比較の結果により、同期信号の完全順序関係が成立すると判定され、コード１の１１行目の関数の操作は許されているものであると判定される。
【０１０９】
（同期処理の正しくない例）
次に、同期処理が正しく記述されていない、間違い（bug）のあるコード例を説明する。図２１のコードは、正しい同期処理が記述されていないコード例を示す図である。図２１は、図１２のコードと略同様であり、異なる部分だけを説明する。
【０１１０】
図２１のコード２は、１０行目においてあるループ処理の関数を含んでいる。１０行目の関数は、変数ｉが「１０００」になるまで繰り返される処理を行う。しかし、スレッド２において、コード１で説明したような同期待ちの関数の記述が抜けている。
【０１１１】
コード２において９行目までは、図１３から図１７を用いて説明した同期処理の正しいコード１と同様に実行される。  
１０行目に、コア２はいくらか時間の掛かる処理を実行する。  
そして１１行目に、コア２はAPI関数である関数「translate_to_exclusive」を実行して、sharedの状態のメモリ領域をexclusiveの状態に変更する。この関数のPCも事前にイベントモニタに登録されているので、イベントモニタ部C23はその関数の呼び出しのイベントを検出する。
【０１１２】
イベントモニタ部C23はそのイベントの情報をイベントコレクタ部ECに送信し、イベントコレクタ部ECはその情報をカスタム部CPに通知する。  
カスタム部CPは、イベントの情報を受信すると、内部状態情報収集部C24を経由して、演算模擬部C21等の情報を収集する。カスタム部CPは、内部状態情報収集部C24から演算模擬部C21等に対応するレジスタやメモリの情報を取得することができるので、関数「translate_to_exclusive」の引数（例えばaddr、size）の値、および戻り値を得ることができる。
【０１１３】
コード２の１１行目におけるベクトルクロック表は、図２２に示す状態となっている。図２２は、コード２の１１行目におけるベクトルクロック表の例を示す図である。すなわち、同期待ちの関数が実行されていないので、スレッド２のスレッド１に対応する要素は「０」のままである。これは、上述したコード１の場合は、同期待ちの関数「wait_until_receive_signal」が実行されたときに、その要素には「１」が上書きされているが、コード２ではそのような処理はされていないからである。
【０１１４】
そして、カスタム部CPは、キャッシュライン情報管理表の対応するアドレスの情報を参照する。コード２の１１行目の関数の実行がされる前のキャッシュライン情報管理表の状態は、図１９に示す通りである。
【０１１５】
カスタム部CPは、各操作の有効性の検証、すなわち、１１行目の関数の実行が許されているものであるか否かを判定するが、コード１で説明したようにここでは、その関数「translate_to_shared」はメモリ領域を「exclusive」の状態から「shared」の状態に変更する関数であるので、許可されているものであると判定される。
【０１１６】
さらに、カスタム部CPは、共有資源に対する排他制御における潜在的な不具合の有無の検証、すなわち、関数「transloate_to_exclusive」の操作が直近のキャッシュ操作と実行順序が入れ替わる可能性があるかを判定する。この判定は、キャッシュライン情報管理表中の「直近のキャッシュ操作のスレッドのベクトルクロックの対角要素」の値と、同期信号を受信したときのスレッドのベクトルクロックの値の比較を行うことによって行われる。
【０１１７】
しかし、図１９のキャッシュライン情報管理表において、直近のキャッシュ操作のスレッド１のベクトルクロックの１番目の対角要素は「０」である。一方、図２２のベクトルクロック表において、スレッド２のベクトルクロックの1番目の要素は「０」のままである。すなわち、比較した２つのベクトルクロックの値は、同じである。よって、このベクトルクロックの値の比較の結果により、同期信号の完全順序関係が成立しないと判定され、コード１の１１行目の関数の操作は許されていないものであると判定される。すなわち、カスタム部CPは、ベクトルクロック表における相対的な順序関係の情報とキャッシュライン情報管理表における相対的な順序関係の情報とを比較することによって、半順序関係となるイベントが発生したか否かを判定する。そして、半順序関係となるイベントは、一のスレッドにおいて他のスレッドへの同期信号の送信処理があり、他のスレッドにおいて前記一のスレッドからの前記同期信号の受信待ち処理がないというイベントである。  
同期信号の完全順序関係が成立しないと判定された関数の実行が検出されると、カスタム部CPは、潜在的不具合判定結果記録表１０７に記録する。
【０１１８】
以上のようにして、図４のプロトコル違反判定処理１２により、違反のあったイベントについての情報が判定結果記録表１０６に蓄積される。具体的には、デバッグ対象プログラムP1について、キャッシュのコンシステンシに関するSWバグを検出することができる。そして、そのバグの検出の際、デバッグ対象プログラムP1自体には全く変更を加える必要がない。
【０１１９】
以上の説明に使用したプロトコル規定は、状態のshared, exclusiveだけについての簡単な例であるが、プロトコル規定の内容が複雑になってもそれに対応したイベントがモニタできればよいので、さまざまなプロトコル規定にも拡張可能である。
【０１２０】
さらに、カスタム部CPによる共有資源に対する排他制御における潜在的な不具合の有無の検証を行っている。よって、カスタム部CPは、同期信号の完全順序関係が成立しないと判定された関数の実行を検出することができるので、デバッグ対象プログラムにおける潜在的な不具合の存在を、表、図形等を用いて画面等に表示して、ユーザに知らせることができる。潜在的不具合判定結果記録表１０７には、直近のキャッシュ操作に関する情報と、その潜在的な違反のあったキャッシュ操作に関する情報が記憶される。
【０１２１】
（ユーザへの表示方法）
以上のように、上述したシミュレータP2によれば、開発中のプログラムであるデバッグ対象プログラムP1について、潜在的な不具合に関する情報が潜在的不具合判定結果記録表１０７に記録される。図２３は、潜在的不具合判定結果記録表１０７の例を示す図である。そして、バグ解析表示プログラムP3により、これらの表に記録されたデータに基づいて、潜在的な不具合の内容を判り易くユーザに示すことができる。  
潜在的不具合判定結果記録表１０７は、アドレス、状態、１つ前の状態、直近のキャッシュ操作、直近のキャッシュ操作のPC、直近のキャッシュ操作のスレッド番号、直近のキャッシュ操作のコア番号、直近のキャッシュ操作の実クロック、このキャッシュ操作、このキャッシュ操作のPC、このキャッシュ操作のスレッド番号、このキャッシュ操作のコア番号及びこのキャッシュ操作の実クロックの各項目を含む。
【０１２２】
以下、そのバグ解析表示プログラムP3によるデバッグを容易にする表示処理及び表示例を、図４を用いて説明する。
【０１２３】
（表示例１：違反ソース行番号表表示）
図２４は、ユーザに示す表示例１としての違反ソース行番号表の表示例を示す図である。図２４は、表示部４の画面上に、潜在的な違反を検出された行毎にまとめて表示した表である。  
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、違反行番号表探索処理１３（図４）を実行し、違反ソース行番号表２０１を生成する。違反ソース行番号表２０１は、潜在的不具合判定結果記録表１０７のデータを基に生成される。
【０１２４】
違反ソース行番号表２０１は、違反種類、違反回数、違反遷移処理ソース行、状態及び直近のキャッシュ操作ソース行の各項目を含む。  
違反の種類は、違反の内容すなわち種別を示し、カスタム部CPが有する判定基準の内容から抽出される。  
違反の回数は、潜在的不具合判定結果記録表１０７の履歴データから、違反の発生した回数をカウントすることによって算出される。  
違反遷移処理ソース行は、違反を発生させたソースコードの行であり、そのソースコードの行に対応するPC値のデバッグ情報から抽出される。図２１では、コード２のプログラムである「test2.c」の１１行目であることが示されている。  
状態は、違反の発生したときの状態を示し、潜在的不具合判定結果記録表１０７から生成される。  
直近のキャッシュ操作ソース行は、潜在的不具合判定結果記録表１０７から抽出される。図２４では、「test2.c」の５行目であることが示されている。
【０１２５】
すなわち、ユーザが、違反ソース行番号表２０１のデータを、表示部４の画面上に表示されるための違反行番号描画処理１４を実行させる指示を本体装置２に対して指示すると、違反行番号描画処理１４が実行され、違反ソース行番号表が画面上に表示される。  
違反遷移処理ソース行と直近のキャッシュ操作ソース行が、違反の種類、違反回数及び状態と共に表示されるので、ユーザは、一見して違反の状態を表形式のイメージで把握することができる。よって、ユーザは、デバッグを容易に行うことができる。
【０１２６】
（表示例２：違反時刻一覧表表示）
さらに、違反に関する時刻のデータを併せて表示する例である。  
図２５は、違反時刻一覧表表示の例を示す図である。図２５の表は、表示部４の画面上に表示される。  
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、違反時刻一覧表示部である違反時刻一覧表描画処理１７を実行し、違反時刻一覧表２０３を生成する。違反時刻一覧表２０３は、判定結果記録表１０６と潜在的不具合判定結果記録表１０７のデータを基に生成される。
【０１２７】
違反時刻一覧表２０３は、違反遷移処理時刻、領域先頭、領域末端、状態及び直近のキャッシュ操作時刻の各項目を含み、判定結果記録表１０６と潜在的不具合判定結果記録表１０７の内容から抽出される。
【０１２８】
違反遷移処理時刻は、違反の発生した時刻を示す。  
領域先頭と領域末端は、違反に関わるメモリ領域先頭と末端のアドレスである。  
状態は、違反の発生したときの状態を示す。  
直近のキャッシュ操作時刻は、その違反に関わる直近のキャッシュ操作時刻を示す。
【０１２９】
ユーザは、違反時刻一覧表２０３のデータを、表示部４の画面上に表示されるための違反時刻一覧表描画処理１７を実行させる指示を本体装置２に対して指示すると、違反時刻一覧表描画処理１７が実行され、違反時刻一覧表が画面上に表示される。  
すなわち、その潜在的な違反の原因となった直近のキャッシュの操作時刻を、ユーザは一見して把握することができる。
【０１３０】
よって、ユーザは、シミュレータP2の実行が終了すると、所定の表示コマンドをCPU２ａに指示し、違反時刻一覧表描画処理１７を実行させることによって、違反時刻一覧表２０３のデータを表形式のイメージで表示部４の画面上に表示させて、デバッグを容易に行うことができる。
【０１３１】
（表示例３：ソースコード強調表示）
図２６は、ソースコード強調表示の例を示す図である。  
潜在的不具合判定結果記録表１０７のデータが生成されれば、その潜在的不具合判定結果記録表１０７のデータに基づいて、違反ソース行のソースコードを強調表示させることができる。なお、違反時刻一覧表２０３のデータに基づいて、違反ソース行のソースコードを強調表示させてもよい。
【０１３２】
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、ソースコード情報抽出処理１５とソースコード描画処理１６を実行し、ソースコード強調表示用の画面２０２のデータを生成する。ソースコード強調表示用の画面２０２は、違反行番号表２０１のデータを基に、ソースコード情報抽出処理１５の処理結果を用いて生成される。
【０１３３】
ソースコード描画処理１６は、違反ソース行番号表２０１における違反遷移処理ソース行及び直近のキャッシュ操作ソース行のデータから、デバッグ対象プログラムP1における対応するソースコードの部分のデータを記憶部３から読み出す。
【０１３４】
ソースコード情報抽出処理１５は、ソースコード描画処理１６において描画されるソースコードの情報を、潜在的不具合判定結果記録表１０７とデバッグ対象プログラムP1から、抽出し、ソースコード描画処理１６へ供給する。具体的には、デバッグ情報に含まれる関数のPC値とソース行番号の対応情報に基づいて、ソースコードの情報が取得される。
【０１３５】
ソースコード描画処理１６は、図２６に示すような所定の配置関係で表示画面データを生成して表示部４に出力する。表示部４の画面上には、表示領域３１が表示される。ソースコード描画処理１５とソースコード情報抽出処理１６が、履歴情報に基づいて、違反とされたデータアクセスに関するソースコードの表示を行うソースコード表示処理部を構成する。
【０１３６】
図２６において、表示領域３１には、違反遷移処理ソース行と直近のキャッシュ操作ソース行が表示される。違反遷移処理ソース行の近傍には所定のマーク、ここでは黒の三角マークが表示され、直近のキャッシュ操作ソース行の近傍には黒の丸マークが表示されて、対応するソース行の位置がユーザに解り易いように表示される。
【０１３７】
よって、ユーザは、潜在的なバグのあるソースコードの部分とそのソースコードに関連するソースコードの部分も表示されるので、直接ソースコードを見ることができ、その結果デバッグが容易となる。
【０１３８】
（表示例４：時系列図）
図２７は、違反が検出された際の関数の時系列表示の例を示す図である。  
違反時刻一覧表２０３のデータが生成されれば、その違反時刻一覧表２０３のデータに基づいて、違反に関わる関数を時系列表示させることができる。
【０１３９】
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは時系列図抽出処理１８を実行し、図２７に示す違反に関わる関数の時系列表示用の画面２０４のデータを生成する。時系列表示用の画面２０４は、潜在的不具合判定結果記録表１０７のデータを基に生成される。
【０１４０】
時系列図抽出処理１８は、実行記録表と違反時刻一覧表２０３と潜在的不具合判定結果記録表１０７のデータから、違反に関わる各関数の時刻データを抽出し、図２７に示すような所定の配置関係で表示画面データを生成して、表示部４に出力する。違反時刻一覧表描画処理１７と時系列図描画処理１８が、履歴情報に基づいて、違反とされるデータアクセスに関わる関数の実行状態を時系列で表示する時系列表示部を構成する。
【０１４１】
図２７の例は、表示部４の画面上には、２つのコアプロセッサと各関数の実行状態が時系列表示されている例である。図２７の時系列表示は、横軸が時間（サイクル数）で、縦軸が各コアに対応し、並列実行単位の実行状態（ここでは各コアで実行される関数の実行状態）が時系列表示されている。
【０１４２】
さらに、図２７では、どの関数が違反に関わる状態遷移を生じさせたかをポップアップウインドウで表示し、かつ違反のコードも違反を発生させた関数に関連付けてポップアップウインドウの中に表示されている。
【０１４３】
図２７では、あるメモリ領域がsharedの状態に変更され（translate_to_shared）、その後コア２によりexclusiveの状態に変更された（translate_to_exclusive）が、その２つの変更に潜在的な違反があることを矢印とポップアップウインドウで示している。
【０１４４】
図２７は、メモリ領域がshared状態にされてからexclusive状態に変更されているが、同期信号の完全順序関係が成立しないと判定されていることを示している。よって、ユーザは、２つのスレッドのそれぞれの違反コードを確認することができる。
【０１４５】
スレッド２には１０行目の処理があるために、関数「translate_to_exclusive」はスレッド１の関数「translate_to_shared」の後に実行されているが、スレッド２には同期待ちの関数が含まれていない。
【０１４６】
例えば、マルチコアシステムにおいて割り当てられるコア数の増加等によりコード２の実行環境が変化すると、１０行目の処理がコア２以外のコアで実行され、スレッド２における関数「translate_to_exclusive」の実行時刻が早まる場合が有り得る。そのような場合、図２７の点線で示すように、スレッド１の関数「translate_to_shared」とスレッド２の関数「translate_to_exclusive」の実行順序が入れ替わる場合がある。
【０１４７】
図２７は、２つのスレッドの２つの関数にそのような同期処理の潜在的な不具合の存在を示すことになる。よって、ユーザは、潜在的なバグの部分に関して、各コア及び各関数が時間経過と共に表示されるので、デバッグが容易となる。
【０１４８】
以上のように、上述した本実施の形態のデバッグ装置によれば、対象プログラムに含まれる同期処理に関わる潜在的な不具合の存在を検出できるので、そのような潜在的なバグを取り除くことができる。
【０１４９】
さらに、上述した本実施の形態のデバッグ装置によれば、潜在的な不具合の存在に関する情報を、プログラム開発者等に分かり易く提示することができる。
【０１５０】
（第２の実施の形態）
上述した第１の実施の形態のデバッグ装置は、PC等のコンピュータ上にソフトウエアプログラムにより実現されているが、第２の実施の形態は、実際の半導体チップを用い、各コアの演算模擬部とキャッシュ模擬部を使わないで、デバッグ支援装置を実現するものである。第１の実施の形態の構成要素と同じ構成要素は、同じ符号を付して説明は省略する。
【０１５１】
図２８は、第２の実施の形態に係るプログラム開発装置１Aの構成を示す構成図である。本体装置２には、デバッグ用のボード２１がケーブルを介して接続されている。ボード２１には、デバッグ対象プログラムP1が実行されるマルチコアプロセッサ２２が搭載される。
【０１５２】
図２９は、マルチコアプロセッサ２２において実行されるプログラムの構成を示す図である。マルチコアプロセッサ２２において実行されるプログラムP11は、デバッグ対象プログラムP1と、各コアのイベントモニタ部としてのイベントモニタプログラムPEMと、各コアの内部状態情報収集部としての内部状態情報収集プログラムPISを含む。
【０１５３】
図３０は、本実施の形態におけるシミュレータP21の構成を説明するための図である。図３０において、３つのコアプロセッサAC0,AC1,AC2とメモリAMは、半導体チップであるマルチコアプロセッサ２２に含まれる要素である。  
３つのコアプロセッサAC0,AC1,AC2はそれぞれ、演算部AC01,AC11,AC21とキャッシュAC02,AC12,AC22を含む。
【０１５４】
イベントモニタ部C03,C13,C23は、プログラムP11のイベントモニタプログラムPEMに含まれる。同様に、内部状態情報収集部C04,C14,C24は、プログラムP11の内部状態情報収集プログラムPISに含まれる。  
カスタム部CPとイベントコレクタ部ECは、シミュレータP21に含まれる。
【０１５５】
図２９のプログラム１１は、マルチコアプロセッサ２２上で実行され、上述したイベントモニタ部の機能と、内部状態情報収集部の機能を実現する。  
また、カスタム部CPとイベントコレクタ部ECは、本体装置２のCPU２ａにより実行される。
【０１５６】
イベントモニタ部、内部状態情報収集部、イベントコレクタ部EC及びカスタム部CPによる実行内容は、第1の実施の形態のイベントモニタ部、内部状態情報収集部、イベントコレクタ部EC及びカスタム部CPと同じである。イベントコレクタ部ECは、イベントモニタプログラムPEMからイベント情報を収集する。カスタム部CPは、内部状態情報収集プログラムPISを介して内部状態情報を収集する。
【０１５７】
よって、第２の実施の形態のプログラム開発装置1Aにおいても、第１の実施の形態と同様の効果を得ることができる。
【０１５８】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明した。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０１５９】
なお、以上説明した動作を実行するプログラムは、コンピュータプログラム製品として、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶媒体に、その全体あるいは一部のプログラムコードが記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムのコードの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のデバッグ支援装置を実現することができる。
【０１６０】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【符号の説明】
【０１６１】
１、１A  プログラム開発装置  、２  本体装置、２ａ  ＣＰＵ、３  記憶部、４  表示部、２１  ボード、２２  半導体チップ
【図１】
2011203803.tif 000003
【図２】
2011203803.tif 000004
【図３】
2011203803.tif 000005
【図４】
2011203803.tif 000006
【図５】
2011203803.tif 000007
【図６】
2011203803.tif 000008
【図７】
2011203803.tif 000009
【図８】
2011203803.tif 000010
【図９】
2011203803.tif 000011
【図１０】
2011203803.tif 000012
【図１１】
2011203803.tif 000013
【図１２】
2011203803.tif 000014
【図１３】
2011203803.tif 000015
【図１４】
2011203803.tif 000016
【図１５】
2011203803.tif 000017
【図１６】
2011203803.tif 000018
【図１７】
2011203803.tif 000019
【図１８】
2011203803.tif 000020
【図１９】
2011203803.tif 000021
【図２０】
2011203803.tif 000022
【図２１】
2011203803.tif 000023
【図２２】
2011203803.tif 000024
【図２３】
2011203803.tif 000025
【図２４】
2011203803.tif 000026
【図２５】
2011203803.tif 000027
【図２６】
2011203803.tif 000028
【図２７】
2011203803.tif 000029
【図２８】
2011203803.tif 000030
【図２９】
2011203803.tif 000031
【図３０】
2011203803.tif 000032