JP2010160704A - デバッグ支援装置 - Google Patents

Abstract

【課題】マルチプロセッサシステムにおいて、並列実行されるプログラムのバグ等に関する情報を正確に検出することができるデバッグ支援装置を提供する。
【解決手段】デバッグ支援装置１は、プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部C1,C2と、複数のCPU によって共有されるメモリの模擬部Ｍと、各CPU模擬部C1,C2とメモリの模擬部M間において発生した所定のイベントを検出するイベントモニタ部C13,C23と、発生した所定のイベントの状態が所定の条件に合致するか否かを判定し、所定の条件に合致したときに、メモリの模擬部Mの状態に関する履歴情報を記録するカスタム部CPと、を有する。
【選択図】図２

Description

本発明は、デバッグ支援装置に関し、特に、並列に実行されるプログラムのデバッグ支援装置に関する。

従来より、複数のコアを有するマルチコア・プロセッサシステムが広く利用されている。マルチコア・プロセッサシステムは、システムに含まれる各コアがキャッシュメモリを持つ並列計算機である場合がある。マルチコア・プロセッサシステムでは、値の一貫性(コンシステンシ)は、ハードウエア（以下、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中に資源の占有状態遷移処理の呼び出しコードを対象プログラム中に埋め込むことにより、資源の占有状態管理を行なう必要がある。その資源管理処理の規約違反を検出し、プログラム開発者に提示する手法として、共有メモリのキャッシュコヒーレンス違反検出を対象とした提案もされている（例えば、特許文献３，特許文献４参照）。しかし、この提案では、並列に動作する複数の処理装置から占有状態遷移処理が呼び出される場合の、違反原因の特定が困難である。

さらに、並列に動作する複数の処理装置からの共有資源利用状況を表示する手法としては、タスク遷移状態と資源利用状況を時系列に図示して性能改善に利用する技術の提案もされている（例えば、特許文献５参照）が、規約違反の検出には利用できない。

また、マルチコア・プロセッサシステムにおいては、上述したコンシステンシの問題以外にも、排他制御における、ロックあるいはアンロックの命令に関する性能、デッドロック発生等の問題もある。

従って、このような問題も含めて、バグ等に関する情報を正確に検出する方法、及びそのバグ等に関する情報を、プログラム開発者等に分かり易く知らしめる方法についても、提案されていない。
特開2006-146412号公報 特開平05-165675号公報 特表2008-517370号公報 米国特許公開US2006-0259698 A1号公報 特開2008-4054号公報

そこで、本発明は、マルチプロセッサシステムにおいて、並列実行されるプログラムのバグ等に関する情報を正確に検出することができるデバッグ支援装置を提供することを目的とする。

さらに、本発明は、バグ等に関する情報を、プログラム開発者等に分かり易く提示することができるデバッグ支援装置を提供することを目的とする。

本発明の一態様によれば、プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部と、前記複数のCPU によって共有される共有資源の模擬部と、各CPU模擬部と前記共有資源間において発生した所定のイベントを検出するイベントモニタ部と、発生した前記所定のイベントの状態が所定の条件に合致するか否かを判定し、前記所定の条件に合致したときに、前記共有資源の状態に関する履歴情報を記録する状態判定部と、を有するデバッグ支援装置を提供することができる。

さらに、本発明の一態様によれば、デバッグ支援装置は、前記履歴情報に基づいて、違反とされた前記データアクセスに関わるソースコードの表示を行うソースコード表示処理部を、さらに有することが好ましい。

本発明によれば、マルチプロセッサシステムにおいて、並列実行されるプログラムのバグ等に関する情報を正確に検出することができるデバッグ支援装置を実現することができる。

さらに、本発明によれば、バグ等に関する情報を、プログラム開発者等に分かり易く提示することができるデバッグ支援装置を実現することができる。

以下、図面を参照して本発明の実施の形態を説明する。
（第１の実施の形態）
（構成）
まず図１に基づき、本発明の第１の実施の形態に係わるプログラム開発装置の構成を説明する。図１は、本実施の形態に係わるプログラム開発装置の構成を示す構成図である。
プログラム開発装置１は、後述する各種ソフトウエアプログラムを実行する中央処理装置（以下、CPUという）２ａを有する本体装置２と、本体装置２と接続され各種ソフトウエアプログラム等を記憶する記憶部３と、本体装置２と接続された表示部４と有して構成されている。なお、図示しないが、ユーザが、各種プログラムを実行させるための指示を与えるための、キーボード、マウス等の入力装置が、本体装置２には接続されている。

記憶部３には、各種ソフトウエアプログラムとして、デバッグ対象プログラムP1と、デバッグ機能付きのシミュレーションプログラム（以下、シミュレータという）P2と、バグ解析表示プログラムP3、プログラムカウンタ（PC）一覧生成プログラムP4が記憶されている。本体装置２のCPU２ａは、記憶部３に記憶されたこれらのプログラムを実行あるいは読み出すことができる。

従って、プログラム開発者（以下、ユーザともいう）は、開発中のプログラムをデバッグあるいはチューニングする場合は、その開発中のプログラムを、記憶部３に記憶させ、開発中のプログラムを、デバッグ対象プログラムP1として指定して、シミュレータP2を実行してデバッグ等することができる。

そして、プログラム開発者は、バグ解析表示プログラムP3により、デバッグの結果を分かり易く、表示部４の画面上に表示させることができる。

開発中のプログラムは、並列計算機であるマルチコア・プロセッサシステム上で実行されるプログラムである。そのマルチコア・プロセッサシステムは、ハードウエアによるコンシステンシを一致させるための機構を有していない。以下、例として、開発中のプログラムは、２つのコアプロセッサ上で、実行されるプログラムであるとして説明する。そして、シミュレータP2は、マルチコア・プロセッサシステムはそれぞれがキャッシュメモリを含む複数のコアプロセッサ（ここでは２つのコアプロセッサ）と、１つのメインメモリを有しているものとして、デバッグのためのシミュレーションを実行するものとして説明する。そして、共有メモリであるメインメモリ上の一部の領域を、コアプロセッサである各処理装置内の非共有のキャッシュメモリにキャッシュする場合、キャッシュのコヒーレンスを保証する必要がある。

（シミュレータの構成）
次に、シミュレータP2の構造について説明する。図２は、シミュレータP2の構成を示す構成図である。
シミュレータP2は、２つのコアプロセッサ（以下、単にコアともいう）を模擬したコアプロセッサ模擬部（以下、コア模擬部という）C1,C2と、メインメモリを模擬したメモリ模擬部Mを含む。コア模擬部C1,C2は、それぞれ、演算模擬部とキャッシュ模擬部とを含む。コア模擬部C1は、演算模擬部C11とキャッシュ模擬部C12とを含み、コア模擬部C2は、演算模擬部C21とキャッシュ模擬部C22とを含む。

シミュレータP2は、さらに、コア模擬部C1用のイベントモニタ部C13と、コア模擬部C2用のイベントモニタ部C23と、コア模擬部C1用の内部状態情報収拾部C14と、コア模擬部C2用の内部状態情報収拾部C24と、イベントコレクタ部ECと、カスタム部CPと、バス模擬部CBとを含む。

コア模擬部C1、C2は、デバッグ対象プログラムP1が実行されるマルチコア・プロセッサシステム（以下、対象プロセッサという）における２つのコアプロセッサに対応する。
演算模擬部C11とC21は、それぞれ対象プロセッサのコアプロセッサの演算部を模擬する処理部である。演算模擬部C11とC21は、各演算部の種々の演算機能を実現する処理部である。

キャッシュ模擬部C12とC22は、それぞれ対象プロセッサにおけるコアプロセッサのキャッシュメモリを模擬する処理部である。
メモリ模擬部Mは、メインメモリを模擬する処理部である。
バス模擬部CBは、対象プロセッサの各コアプロセッサとメインメモリを接続するバスを模擬する処理部である。

イベントモニタ部C13とC23は、それぞれコア模擬部C1、C2の内部で発生する各イベントを収集しイベントコレクタ部ECに伝達する機能を実現する処理部である。言い換えると、各イベントモニタ部は、模擬部間のデータを監視する処理部である。具体的には、各イベントモニタ部は、対応する演算模擬部とキャッシュ模擬部間、キャッシュ模擬部とメモリ模擬部間、及び演算模擬部とメモリ模擬部間の、データのやりとりを監視する。

イベントとしては、キャッシュアクセス、キャッシュリフィル要求、キャッシュ・ライトバック要求などがある。また、イベントモニタ部C13,C23は、演算部のポインタが、事前に登録しておいたプログラムカウンタ(PC)の値になったときに、イベントとして通知する機能も、有する。例えば、メモリ領域の状態を変更するような関数の先頭を事前に登録しておくことにより、その関数の実行をイベントの発生として検出することができる。

例えば、図２に示すように、コア模擬部C1における演算模擬部C11からキャッシュ模擬部C12にキャッシュアクセスｃａがあれば、そのアクセスが監視される。さらに、イベントモニタ部C13は、キャッシュ模擬部C12とメモリ模擬部M間のキャッシュリフィル要求ｃｒ、あるいはキャッシュ・ライトバック要求ｗｂ等のイベントを監視する。さらに、イベントモニタ部C13は、演算模擬部C11からメモリ模擬部Mへのキャッシュをスルーした読み出し要求ｔａ等も監視する。

イベントの監視は、シミュレータP2の実行中におけるメモリ空間上の所定のアドレスへのアクセス等の有無を監視することにより行われる。たとえば、各イベントモニタ部は、所定のアドレスのデータの読み出しあるいは書き込みがあれば、所定のイベントが発生したと判定し、そのイベント情報をイベントコレクタ部ECに伝達することができる。

イベントコレクタ部ECは、各イベントモニタ部から伝達された情報およびバス模擬部CBからの情報を収集し、所定のイベントが発生すると、その発生したイベント情報をカスタム部CPに伝達し、カスタム部CPを呼び出す。呼び出されたカスタム部CPは、後述するような判定処理を実行する。後述するように、カスタム部CPは、状態表とプロトコル規定表を参照して、発生したイベントの状態が所定の条件に合致するか否かを判定し、所定の条件に合致したときに、共有資源であるメインメモリの状態に関する履歴情報を記録する状態判定部を構成する。

カスタム部CPは、受信したイベント情報に基づいて、所定の条件に合致しているか等の所定のチェックを行うために、イベントコレクタ部ECから呼び出され、その所定のチェックを行う機能を実現する処理部である。このカスタム部CPのチェック内容すなわち判定の条件は、ユーザが、目的あるいはチェックしたい内容に応じて、設定あるいは変更してカスタマイズできるようになっている。この設定された条件等は、後述するプロトコル規定表として、記憶部３に記憶される。

上述した例であれば、あるページがexclusive状態に既にされているにも拘わらず、重ねて同じページにexclusive状態にするコマンドが再度発行された場合には、違反設定があったとする判定の条件が、予め設定されているとする。その場合、カスタム部CPは、exclusive状態にするイベントが発生すると、その条件が満たされるか否かのチェックを行う。再度exclusive状態にするコマンドが発生すると、カスタム部CPは、違反発生を判定することになる。よって、ユーザは、カスタム部CPに対して、チェックしたい内容を自由に設定することができる。

内部状態情報収集部C14,C24は、対応するコアプロセッサ内部のレジスタやキャッシュメモリなどの値を読み出す機能を実現する処理部である。内部状態情報収集部C14,C24は、それぞれカスタム部CPからの要求に応じて、対応するコアの各模擬部及びメモリ模擬部Mのデータを収集する。収集されるデータには、処理対象のデータ等だけでなく、サイクル数の情報等のデータも含まれる。

（動作）
次に、プログラム開発装置１のデバッグ動作を説明する。
ユーザすなわちプログラム開発者は、開発したあるいは開発中のプログラムをデバッグするために、シミュレータP2とバグ解析表示プログラムP3を実行させる。シミュレータP2は、デバッグ対象プログラムP1を、シミュレータP2において実行し、バグ解析表示プログラムP3は、シミュレータP2の実行結果に基づいて、発生したバグに関して、バグを解析するのに分かり易い表示を、表示部４の画面上に表示させることができる。

（プログラムカウンタ一覧の作成と登録）
このようなデバッグ処理が、プログラム開発装置１において実行されるが、前処理として、プログラムカウンタ一覧（以下、PC一覧ともいう）が生成される。PC一覧は、イベントとプログラムカウンタ値の対応関係を示すデータである。
プログラム１１は、ソースプログラムであり、コンパイルされてオブジェクトプログラムに変換される。その変換されたオブジェクトプログラムが、シミュレータP2上で実行される。

従って、オブジェクトプログラムが生成されると、そのオブジェクトプログラムからプログラムカウンタ（PC）一覧のデータが予め作成され、各イベントモニタ部C13,C23に登録される。そして、そのプログラムカウンタ一覧に基づいて、各イベントモニタ部C13,C23は、所定のイベントが発生したか否かの判定を行う。

図３は、予め生成されて登録されるPC一覧を生成し、イベントモニタ部に登録するためのPC一覧生成プログラムの処理の流れの例を示すフローチャートである。図１に示すように、このPC一覧生成プログラムP4も、記憶部３に記憶され、本体装置２のCPU２ａによって実行される。

また、どのようなイベントを監視するかがユーザにより、事前に決められている。よって、監視すべきイベント（以下、監視対象イベントともいう）の名前は、メモリアクセス情報として、所定のライブラリ（以下、メモリアクセスライブラリという）に予め登録される。ユーザは、このメモリアクセスライブラリの名前一覧の内容を変更することにより、監視対象イベントを自由に設定し、変更することができる。

図３に示すように、このメモリアクセスライブラリの名前一覧１０１のデータが設定された後、本体装置２のCPU２ａは、その名前一覧１０１を基に、対応するオブジェクトプログラムについてのPC一覧１０２を作成する（ステップS1）。

CPU２ａは、作成されたPC一覧１０２のデータを、対応する各イベントモニタ部C13,C23に登録する（ステップS2）。PC一覧１０２のデータは、ソースプログラム１１中の監視すべきコードに対応する、オブジェクトコードのプログラムカウンタ（PC）の値（以下、PC値という）のデータである。

例えば、「allocate_shared」のコマンドが監視対象イベントの場合、「allocate_shared」のコードに対応する、オブジェクトコードのPC値が、イベントの内容あるいは命令と共に、PC一覧１０２に登録される。

すなわち、各イベントモニタ部C13,C23には、対応するコアに関して、監視対象イベントに対応するオブジェクトコードのPC値が登録される。

また、ユーザは、上述したチェックしたいイベントに応じた条件等も、後述するプロトコル規定表として予め設定し登録する。
以下、プログラム開発装置１のデバッグ処理関連の全体の処理の流れと共に、各処理部の処理の内容を説明する。

（プロトコル違反の検出処理）
図４は、プログラム開発装置１のデバッグ処理関連の全体の処理の流れを説明するための図である。
図４に示すように、デバッグ対象プログラムP1が、シミュレータP2により実行される。その実行処理１１では、PC一覧１０２のデータを用いて、図２のイベントモニタ部C13,C23が、上述した所定のイベントの発生を監視し、イベントコレクタ部ECは、検出された所定のイベント情報を、実行記録データとして、記憶部３の実行記録表１０３に記憶する。実行処理１１は、図２における、イベントモニタ部C13,C23、イベントコレクタ部EC、及びカスタム部CPによって実行される。

まず、実行処理１１におけるイベントモニタ部C13,C23の処理の内容を説明する。
（イベントモニタ部の処理）
図５は、イベントモニタ部の演算模擬部の実行状態を監視する処理の流れの例を示すフローチャートである。
デバッグ対象プログラムP1が実行されると、イベントモニタ部C13,C23は、演算模擬部C11,C21において実行中のプログラムのPC値を監視する（ステップS11）。監視しているPC値が、PC一覧１０２に予め登録されているいずれかのPC値と一致するか否かが、判定される（ステップS12）。

不一致の場合は、ステップS12でNOとなり、処理は、何もせずにステップS11に戻る。
一致した場合は、ユーザが監視したいとして設定したイベントが発生したことを意味するので、ステップS12でYESとなり、イベントモニタ部は、発生したイベントの情報をイベントコレクタ部ECに伝達する（ステップS13）。イベント情報は、イベントを発生したコアプロセッサ（すなわち処理装置）、PC値及びイベントの内容の情報を含む。

以上のように、演算模擬部に対応するコアプロセッサのCPUが、キャッシュ模擬部に対応するキャッシュメモリあるいはメモリ模擬部に対応するメインメモリに対して、予め設定されたアクセス等を行うと、イベントモニタ部は、そのイベントの情報を、イベントコレクタ部ECへ伝達する。

さらに、イベントモニタ部C13,C23は、キャッシュ模擬部に対応するキャッシュメモリとメモリ模擬部に対応するメインメモリとの間で、発生した通信も監視する。具体的には、図６に示すような処理が行われる。通信は、例えば、キャッシュリフィルがあった場合に発生する。
図６は、イベントモニタ部のリソース間の処理内容を監視する処理の流れの例を示すフローチャートである。

デバッグ対象プログラムが実行されると、イベントモニタ部C13,C23は、キャッシュ模擬部とメモリ模擬部との間で、発生した通信を監視する（ステップS21）。
その通信が有るか否かを監視し（ステップS22）、通信がなければ、すなわち発生しなければ、ステップS22でNOとなり、処理は、何もせずステップS21に戻る。

通信が有れば、すなわち発生したときは、ステップS22でYESとなり、その通信のイベントをイベントコレクタ部ECに伝達する（ステップS23）。
以上のように、実行処理１１では、キャッシュ模擬部に対応するキャッシュメモリとメモリ模擬部に対応するメインメモリとの間で通信があれば、そのイベントの情報を、イベントコレクタ部ECへ伝達する。

実行処理１１では、イベントコレクタ部ECは、各イベントモニタ部からのイベントの情報を受信すると、カスタム部CPに受信したイベント情報を伝達する。

（カスタム部の処理）
カスタム部CPは、イベント情報を受信すると、内部状態情報収集部C14,C24を介して、イベント毎に予め決められたデータを収集し、イベント情報を、実行記録表１０３に記録する。すなわち、状態判定部としてのカスタム部CPは、イベント情報を受信するとき、そのイベントに対応して予め決められた情報を、内部状態情報収集部C14,C24を介して収集して、受信したイベント情報と共に、イベントのプロファイルとして、実行記録表１０３に記録する。例えば、あるイベントについては、引数１が所定のレジスタに登録されているので、そのレジスタのデータを収集するように、カスタム部CPでは、内部状態情報収集部を介して収集すべきデータが予め決められている。

（実行記録表）
図７は、実行記録表１０３の例を示す図である。図７の実行記録表１０３に記録される実行記録データとしてのイベント情報は、処理装置、時刻、PC値、内容、１以上の引数、戻り値の各項目データを含む。発生したイベント毎に、カスタム部CPは、そのイベントの情報を、内部状態収集部を介して収集したデータと共に記録する。

例えば、図７の１行目には、コア１で実行された「Start Thread」は、コア１の処理装置で、「110550」の時刻（サイクル値）に、「0x2000」のプログラムカウンタ値のところで発生し、その引数は、「0x80A0」であったことが示されている。
よって、実行記録表１０３には、各CPU模擬部における並列処理単位である関数、スレッド等の生成、開始及び終了、また、メモリの割り当て、状態遷移、読み出し、書き込み及び解放のデータが含まれる。

カスタム部CPは、イベント情報を、実行処理１１の実行記録データとして、図７に示す実行記録表１０３に記録していく。
カスタム部CPは、図７のイベント情報に基づいて、次に説明する図８の状態表の状態データを作成する。図８は、状態表の例を示す図である。
（状態表）
図８の状態表１０４は、メモリ領域の領域先頭、領域末端、割り当て時刻（サイクル数）、割り当てPC、割り当て処理装置、最終状態遷移処理時刻、最終状態遷移処理PC、最終状態遷移処理装置、状態の各項目を含む。あるメモリ領域がshared状態にされるとき、そのshared状態にするイベントが発生する。そして、そのshared状態が解除されるときも、その解除のイベントが発生する。そして、その解除のイベントに応じて、状態表１０４から、sharedにされたメモリ領域が発生したことを示す状態データが削除される。

従って、カスタム部CPは、イベントの発生に応じて、メモリ領域の状態の遷移を、状態表１０４に書き込んでいく。そして、カスタム部CPは、状態遷移操作に応じて、実行記録表１０３を先頭から読み出して、遷移された状態が消滅すれば、状態表１０４からその状態データは削除される。よって、状態表の内容、すなわち状態データは、デバッグ対象プログラムP1の実行に伴って、発生しては消滅することを繰り返すように変化する。

図８の１行目には、shared状態にされたメモリ領域について、上述した各項目のデータが、１つの状態データとして記憶されていることを示している。
すなわち、状態表１０４は、コアプロセッサによるリソースに対する状態遷移操作に従って更新され、遷移した状態が無くなれば、その状態データは、状態表１０４から削除される。

また、プログラム中のある命令の実行がバグになるのは、上述した例であれば、shared状態のメモリ領域にデータをwriteするような場合である。そのような違反命令の実行の判断基準が予め規定されていて、表データとして、記憶部３に記憶されている。

（プロトコル規定表）
図９は、その表データ（以下、プロトコル規定表という）の例を示す図である。図９のプロトコル規定表１０５は、操作毎に、メモリ領域の状態に応じて、メモリアクセスプロトコルの違反であるか否かを示す表データである。図９のプロトコル規定表１０５には、判定基準データとして、各命令すなわち各操作について、有効か無効（違反）か、メモリ領域がexclusive状態の場合、shared状態の場合の各項目を含んでいる。

なお、ここでは、違反の判定基準データは、表形式のデータであるが、表形式のデータでなくてもよい。
図４のプロトコル違反判定処理１２では、カスタム部CPが、イベント情報を受信すると、プロトコル規定表１０５を参照して、実行記録１０３と状態表１０４のデータに基づいて、プロトコル違反の判定を行う。
違反と判定されると、カスタム部CPは、図１０に示す判定結果記録表１０６にそのプロトコル違反のデータを記憶する。

（判定結果記録表）
図１０は、判定結果記録表の例を示す図である。図１０の判定結果記録表１０６は、メモリアクセスプロトコル違反が有りと判定されたときにおける、メモリ領域の領域先頭、領域末端、割り当て時刻（サイクル数）、割り当てPC、割り当て処理装置、最終状態遷移処理時刻、最終状態遷移処理PC、最終状態遷移処理装置、状態、違反遷移処理時刻、違反遷移処理ＰＣ及び違反遷移処理装置の各項目を含む。

図１０の判定結果記録表１０６は、違反があった時における、状態表１０４のデータと、さらに違反遷移処理時刻、違反遷移処理PC及び違反遷移処理装置のデータが、カスタム部CPによって、違反のプロファイルとして、記録される。よって、判定結果記録表１０６には、繰り返し発生した違反も、全て記録されることになる。すなわち、カスタム部CPは、イベントが発生したときに所定の条件が合致すると、共有資源としてのメインメモリの状態に関する情報を、履歴情報として判定結果記録表１０６に記録する。
図２の状態表１０４は、状態の遷移に伴って、記憶されるデータは発生し消滅する表であるが、図１０の判定結果記録表１０６は、カスタム部CPが、更新前の状態と状態遷移操作が、プロトコル規定表１０５の条件を満たすか否かを判定し、違反があるとされたデータを、追加していく表である。

（プログラム例を用いたバグの検出例）
ここで、シミュレータP2とバグ解析表示プログラムP3の動作を、プログラム例を用いて説明する。
図１１は、バグのあるプログラム例の一部の例を示す図である。図１１に示すプログラム２１は、shared状態のメモリ領域中のあるラインに間違って値を書く、間違い(bug)のあるプログラムである。

具体的には、プログラム２１において、３行目で、コア1はshared状態のメモリを確保する。４行目で、コア1はshared状態のメモリにreadを行う。５行目で、コア1は、shared状態のメモリ領域に、writeを行う。しかし、shared状態のメモリ領域の、writeは正しくない。よって、このバグが、後述するように、シミュレータP2により検出され、バグ内容が画面に出力される。図１１において、「sw_on_core1()」は、コア１の上で、「sw_on_core2()」は、コア２の上で実行されるとする。

また、８行目で、コア２はshared状態の領域に対してreadを行うが、shared状態の領域へのreadは正しい。

図１１のプログラム２１についての、イベントモニタ部、イベントコレクタ部EC及びカスタム部CPの動作を説明する。
３行目の関数「allocate_shared」の実行により、コア1はshared状態のメモリを確保する。この関数のPC値は、事前にその関数を実行する演算模擬部を監視するイベントモニタ部に登録されているので、イベントモニタ部は、その関数の実行をイベントとして検出することができる。イベントモニタ部は、検出したイベントの情報をイベントコレクタ部ECに送信する。イベントコレクタ部ECは、受信したイベントの情報をカスタム部CPに通知する。

カスタム部CPは、イベントの情報を受信すると、内部状態情報収集部を経由して、演算模擬部等の所定の情報を収集する。カスタム部CPは、内部状態情報収集部から演算模擬部等に対応するレジスタやメモリの情報を取得することができるので、関数「allocate_shared」についての所定の情報として、引数１（例えばsize）の値、および戻り値を得ることができる。つまり、カスタム部CPは、メモリ領域をshared状態にするイベントを検出することができ、そのイベント情報を、実行記録表１０３に記憶する。

カスタム部CPは、プロトコル規定表１０５を参照して、実行記録表１０３に記録されたイベント情報に基づき、プロトコル違反が発生したか否かを判定するが、３行目の関数の実行においては、プロトコル違反は、発生していない。

また、プログラム２１における４行目で、コア1はshared状態のメモリに対してreadをする。イベントモニタ部は、readのメモリアクセスをイベントとしてイベントコレクタECに伝える。イベントコレクタ部ECは、そのイベントをカスタム部CPに伝える。カスタム部CPは、そのイベント情報を、実行記録表１０３に記憶する。

カスタム部CPは、プロトコル規定表１０５を参照して、実行記録表１０３に記録されたイベント情報に基づき、プロトコル違反が発生したか否かを判定する。プロトコル規定表１０５には、shared状態のメモリ領域のデータをreadするのは、プロトコル違反でないと規定されている。よって、カスタム部CPは、実行記録表１０３のイベント情報の履歴データを参照し、readされるメモリ領域は、shared状態であることを確認でき、さらにプロトコル規定表１０５にはそのreadは、プロトコル違反ではないと規定されているので、４行目のshared状態のメモリ領域からのreadは正しい、すなわちプロトコル違反ではない、と判定する。なお、必要であれば、そのプロトコル違反の無い旨を画面等に出力するようにしてもよい。

５行目で、コア1は、shared状態のメモリ領域に、writeをする。上述した手順と同様の手順で、カスタム部CPにwriteのイベント情報が伝えられ、カスタム部CPは、このwriteのメモリアクセスが正しいかどうか、すなわち所定の条件に違反していないかを、実行記録表１０３のイベント情報の履歴データをチェックすることによって、判定する。この場合、shared状態のメモリ領域への、writeは正しくない。プロトコル規定表１０５には、shared状態のメモリ領域にデータをwriteするのは、プロトコル違反であると規定されている。すなわち、カスタム部CPは、実行記録表１０３のイベント情報の履歴データを参照することによって、writeするメモリ領域がshared状態にあることが、判定できる。さらに、カスタム部CPは、プロトコル規定表１０５を参照して、shared状態のメモリ領域へのwriteがプロトコル違反であることが判るので、５行目のwriteは、正しくないと、判定することができる。

そして、カスタム部CPは、判定結果記録表１０６にそのプロトコル違反のデータを記憶し、違反アクセスがあったことを、画面等に出力する。違反アクセスのあったことを示すデータの出力及び表示方法については後述する。

さらに、８行目で、コア２はshared状態の領域に対してreadを行う。５行目の場合と同様に、イベントの情報がカスタム部CP伝えられる。カスタム部CPは、プロトコル規定表１０５を参照して、shared状態のメモリ領域からのreadは正しいので、プロトコル違反とは判定しない。

図１２は、バグのある他のプログラムの一部の例を示す図である。図１２に示すプログラム２２は、あるプロセッサが、他のコアプロセッサによってexclusive状態にされたメモリのラインに、間違ってアクセスする、間違い(bug)のあるプログラムである。

具体的には、プログラム２２の３行目において、コア１がexclusive状態のメモリ領域を確保する。この関数のPC値も、事前にイベントモニタ部に登録されているので、その関数の呼び出しのイベントは、イベントモニタ部によって検出され、そのイベントの情報がイベントコレクタ部ECに送信される。イベントコレクタ部ECは、そのイベント情報をカスタム部CPに通知する。

カスタム部CPは、上述したshared状態の場合と同様に、イベント情報として、exclusive状態にされたメモリ領域の情報を、実行記録表１０３に記憶する。

４行目において、コア１はexclusive状態のメモリ領域からreadを行う。そのreadのイベントは、イベント情報としてカスタム部CPに伝えられる。カスタム部CPでは、実行記録表１０３のイベント情報の履歴データと、プロトコル規定表１０５とを参照して、そのアクセス（read）が正しいかどうかを判定する。

この場合、そのメモリ領域をexclusive状態にした、ownerであるコア１からのreadであるので、そのアクセスは正しい。必要であればその旨を、画面等に表示するようにしてもよい。

また、５行目において、コア1は、exclusive状態のメモリにwriteを行う。そのwriteのイベントは、イベント情報としてカスタム部CPに伝えられる。カスタム部CPは、exclusive状態のメモリ領域に対する、ownerであるコア１からのwriteのメモリアクセスは正しいので、そのまま、次の行の命令の実行が継続して行われる。

８行目において、コア２はexclusive状態の領域に対して、readを行う。カスタム部CPには、readのイベントの情報が伝えられる。exclusive状態の領域に対して、owner以外のコアプロセッサからのreadもしくはwriteのアクセスは、プロトコル規定表１０５により、プロトコル違反であると、規定されている。よって、カスタム部CPは、８行目のwriteは、違反アクセスすなわちプロトコル違反であることを、画面等に表示して、ユーザに知らせることができる。このユーザへの告知の方法については後述する。

以上のようにして、図４のプロトコル違反判定処理１２により、違反のあったイベントについての情報が、図１０の判定結果記録表１０６に蓄積される。具体的には、デバッグ対象プログラムP1について、キャッシュのコンシステンシに関する、SWバグを検出することができる。そして、上述したように、そのバグの検出の際、デバッグ対象プログラムP1自体には、全く変更を加える必要がない。

以上の説明に使用したプロトコル規定は、状態のshared, exclusiveだけについての簡単な例であるが、プロトコル規定の内容が複雑になっても、それに対応したイベントがモニタできればよいので、さまざまなプロトコル規定にも拡張可能である。

（ユーザへの表示方法）
以上のように、上述したシミュレータP2によれば、開発中のプログラムであるデバッグ対象プログラムP1について、発生したバグに関する情報が、図７の実行記録表、図８の状態表、及び図１０の判定結果記録表１０６に記録される。そして、バグ解析表示プログラムP3により、これらの表に記録されたデータに基づいて、バグの内容を判り易くユーザに示すことができる。
以下、そのバグ解析表示プログラムP3による、デバッグを容易にする表示処理及び表示例を、図４を用いて説明する。

（表示例１：違反行番号表表示）
図１３は、ユーザに示す表示例１としての違反行番号表の表示例を示す図である。図１３の表は、表示部４の画面上に表示される。
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、違反行番号表探索処理１３（図４）を実行し、図１３の違反行番号表を生成する。違反行番号表２０１は、判定結果記録表１０６のデータを基に、さらに実行記録表１０３と状態表１０４を参照して、生成される。

図１３の違反行番号表２０１は、違反種類、違反回数、違反遷移処理ソース行、状態、割り当てソース行、及び最終状態遷移処理ソース行の各項目を含む。
違反の種類は、違反の内容すなわち種別を示し、プロトコル規定表１０５の内容から抽出される。

違反の回数は、実行記録表１０３のイベント情報の履歴データから、違反の発生した回数をカウントすることによって、算出される。
違反遷移処理ソース行は、違反を発生させたソースコードの行であり、そのソースコードの行に対応するPC値のデバッグ情報から抽出される。
状態は、違反の発生したときの状態を示し、状態表１０４から生成される。

割り当てソース行は、違反のメモリ領域の割り当てを行ったソースコードの行を示し、状態表１０４の割り当てPC値のデバッグ情報から抽出される。割り当てソース行は、例えばそのメモリ領域をallocateしたソース行である。図１３では、「test1.c」の２０行目であることが示されている。

最終状態遷移処理ソース行は、その違反に関わるメモリ領域の状態が最後に正常に遷移したソースコードの行を示し、状態表１０４の最終状態遷移処理PC値のデバッグ情報から抽出される。

ユーザは、図１３の違反行番号表２０１のデータを、表示部４の画面上に表示されるための違反行番号描画処理１４を実行させる指示を本体装置２に対して指示すると、違反行番号描画処理１４が実行され、図１３の表が、画面上に表示される。
すなわち、その領域を割り当てた原因となったソースコードの行（割り当てソース行）と、その状態を設定した原因となったソースコードの行（最終状態遷移処理ソース行）が、違反の発生したソースコードの行（違反遷移処理ソース行）と共に、ユーザは一見して把握することができる。

よって、ユーザは、シミュレータP2の実行が終了すると、所定の表示コマンドをCPU２ａに指示して、違反行番号探索処理１３と違反行番号描画処理１４を実行させることによって、違反行番号表２０１のデータを、図１３の表形式のイメージで、表示部４の画面上に表示させて、デバッグを容易に行うことができる。なお、上述した実施の形態では、シミュレータP2が完全に終了した後に、ユーザへの表示が行われているが、シミュレータP2をデバッグ命令などで一時停止させた場合に、その時点までの事象について、上述したような表示が行われるようにしてもよい。

（表示例２：ソースコード強調表示）
図１４は、ソースコード強調表示の例を示す図である。
図１３の違反行番号表２０１のデータが生成されれば、その違反行番号表２０１のデータに基づいて、違反行のソースコードを強調表示させることができる。

ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、ソースコード情報抽出処理１５とソースコード描画処理１６を実行し、図１４のソースコード強調表示用の画面２０２のデータを生成する。ソースコード強調表示用の画面２０２は、違反行番号表２０１のデータを基に、さらにソースコード情報抽出処理１５の処理結果を用いて、生成される。

ソースコード描画処理１６は、図１３における違反遷移処理ソース行、割り当てソース行及び最終状態遷移処理ソース行のデータから、デバッグ対象プログラムP1における対応するソースコードの部分のデータを記憶部３から読み出す。

ソースコード情報抽出処理１５は、ソースコード描画処理１６において描画されるソースコードの情報を、判定結果記録表１０６とデバッグ対象プログラムP1から、抽出し、ソースコード描画処理１６へ供給する。具体的には、デバッグ情報に含まれる関数のPC値と、ソース行番号の対応情報に基づいて、ソースコードの情報が取得される。

ソースコード描画処理１６は、図１４に示すような、所定の配置関係で、表示画面データを生成して、表示部４に出力する。表示部４の画面上には、３つの表示領域３１，３２，３３が、所定の配置関係で、表示される。ソースコード描画処理１５とソースコード情報抽出処理１６が、履歴情報に基づいて、違反とされたデータアクセスに関するソースコードの表示を行うソースコード表示処理部を構成する。

図１４において、表示領域３１には、割り当てソース行を含む複数のソース行が表示され、表示領域３２は、違反遷移処理ソース行を含む複数のソース行が表示され、表示領域３３には、最終状態遷移処理ソース行を含む複数のソース行が表示される。

よって、ユーザは、バグのあったソースコードを含むソースコードの部分と、そのソースコードに関連する、状態の開始と終了に関わるソースコードの部分も表示されるので、直接ソースコードを見ることができ、その結果デバッグが容易となる。

（表示例３：違反時刻一覧表表示）
さらに、違反に関する時刻のデータを併せて表示する例である。
図１５は、違反時刻一覧表表示の例を示す図である。図１５の表は、表示部４の画面上に表示される。
ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、違反時刻一覧表描画処理１７を実行し、図１５の違反時刻一覧表を生成する。違反時刻一覧表２０３は、判定結果記録表１０６のデータを基に、生成される。

図１５の違反時刻一覧表２０３は、違反遷移処理時刻、領域先頭、違反末端、状態、割り当て時刻、及び最終状態遷移処理時刻の各項目を含み、判定結果記録表１０６の内容から抽出される。

違反遷移処理時刻は、違反の発生した時刻を示す。
領域先頭は、違反に関わるメモリ領域先頭のアドレスである。
状態は、違反の発生したときの状態を示す。

割り当て時刻は、その違反に関わるメモリ領域を割り当てた時刻を示す。
最終状態遷移処理時刻は、その違反に関わるメモリ領域の状態が最後に正常に遷移した時刻を示す。

ユーザは、図１５の違反時刻一覧表２０３のデータを、表示部４の画面上に表示されるための違反時刻一覧表描画処理１７を実行させる指示を本体装置２に対して指示すると、違反時刻一覧表描画処理１７が実行され、図１５の表が、画面上に表示される。
すなわち、その領域を割り当てた原因となった時刻（割り当て時刻）と、その状態が終了する時刻（最終状態遷移処理時刻）が、違反の発生した時刻（違反遷移処理時刻）と共に、ユーザは一見して把握することができる。

よって、ユーザは、シミュレータP2の実行が終了すると、所定の表示コマンドをCPU２ａに指示することによって、違反時刻一覧表描画処理１７を実行させることによって、違反時刻一覧表２０３のデータを、図１５の表形式のイメージで、表示部４の画面上に表示させて、デバッグを容易に行うことができる。

（表示例４：時系列図）
図１６は、違反が検出された際の関数の時系列表示の例を示す図である。
図１５の違反時刻一覧表２０３のデータが生成されれば、その違反時刻一覧表２０３のデータに基づいて、違反に関わる関数を時系列表示させることができる。

ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、時系列図抽出処理１８を実行し、図１６に示す、違反に関わる関数の時系列表示用の画面２０４のデータを生成する。時系列表示用の画面２０４は、判定結果記録表１０６のデータを基に、生成される。

時系列図抽出処理１８は、図１５の違反時刻一覧表２０３と判定結果記録表１０６のデータから、違反に関わる各関数の時刻データを抽出し、図１６に示すような、所定の配置関係で、表示画面データを生成して、表示部４に出力する。違反時刻一覧表描画処理１７と時系列図描画処理１８が、履歴情報に基づいて、違反とされるデータアクセスに関わる関数の実行状態を時系列で表示する時系列表示部を構成する。

図１６の例は、表示部４の画面上には、３つのコアプロセッサと各関数の実行状態が時系列表示されている例である。図１６の時系列表示は、横軸が、時間（サイクル数）で、縦軸が、各コアに対応し、並列実行単位の実行状態（ここでは各コアで実行される関数の実行状態）が、時系列表示されている。

さらに、画面の一部、ここでは、上側の領域には、関連するメモリ領域の値と、その状態が示されている。なお、図１６では、どの関数が、状態遷移を生じさせたかを、ポップアップウインドウで表示し、かつ違反のコードも、違反を発生させた関数に関連付けてポップアップウインドウの中に表示されている。

図１６では、あるメモリ領域がsharedの状態で割り当てられ（allocate shared）、その後コア１によりexclusiveの状態にされた（open exclusive）が、その後、コア２によってさらにexclusiveの状態にしようとした（open exclusive）場合を示す。２回目のexclusiveのopenは、プロトコル違反である。よって、その違反の状態に関わる各コアプロセッサと、各関数と、その状態の変化が、時系列で表示されるので、ユーザは、バグの部分に関して、各コア、各関数、及びメモリ領域の状態が、時間経過と共に表示されるので、デバッグが容易となる。

なお、変形例として、違反を発生させた行が、以前に違反を発生させないで実行されたことがあるか否かを探索し、図１６と同様な時系列図を表示させるようにしてもよい。
図１７は、図１６に対応する、違反を発生させた行が、以前に違反を発生させないで実行されたときの時系列表示の例を示す図である。

ユーザが、図示しない入力装置を用いて、所定の指示操作を本体装置２に対して行うと、CPU２ａは、類似箇所探索処理１９を実行し、図１６に示す、違反に関わる関数であって、以前に違反を発生させないで実行されたときの時系列表示用の画面２０５のデータを、判定結果記録表１０６を探索して抽出して、生成する。類似箇所探索処理１９は、履歴情報から、違反とされたデータアクセスに関わる関数が、違反を発生させないで実行されたときの実行状態のデータを探索する探索処理部を構成する。

時系列図抽出処理１８は、類似箇所探索処理１９によって生成された、違反に関わる各関数であって過去において違反を発生させなかったときの時刻データに基づいて、図１７に示すような、所定の配置関係で、表示画面データを生成して、表示部４に出力する。
図１７は、図１６と同様な配置関係で、どの関数が、どのような状態遷移を生じさせたかを、ポップアップウインドウで表示し、かつ違反を発生させた関数が違反を発生させていないことも併せてポップアップウインドウの中に表示されている。

図１６では、違反を発生させていたコア２の関数Ｂのコードが、図１７では、違反を発生させていないことが示されている。
よって、図１６と図１７の両方を生成して表示させることによって、ユーザは、違反を発生させた関数が、違反を発生させた状況と、違反を発生させていない状況の両方を時間経過と共に表示させて比較できるので、プロトコル違反時に何が違反の原因になったかの原因の追求が容易となる。

以上のように、本実施の形態によれば、SWによりキャッシュのコンシステンシを保つシステムにおいて、バグに関する情報を正確に検出できる。
また、その検出されたバグに関する情報を、ユーザに分かり易く表示して提供することによって、バグの原因解析を容易にすることができる。

（第２の実施の形態）
第１の実施の形態では、SWによりキャッシュのコンシステンシを保つシステムにおけるバグを検出するシステムであったが、第２の実施の形態では、メインメモリの排他制御に関する情報を検出するシステムに関する。

すなわち、本実施の形態では、イベントモニタ部に排他制御のためのロック及びアンロックを行うコードのPC値がイベントとして登録され、プロトコル規定表には、その排他制御の検証をするための条件の情報が登録される。

よって、本実施の形態におけるシミュレータP2のソフトウエアの構成は、図２に示す第１の実施の形態の構成と同じであるが、本実施の形態は、SWによりキャッシュのコンシステンシを保つシステムにおけるバグを検出するのではなく、排他制御における同期状態を検出するようにしたことが、第１の実施の形態と異なる。

マルチコア・プロセッサシステムで実行されるプログラムでは、排他制御処理が必要となる。そのため、通常、排他制御は、tas命令(test-and-set命令)もしくはこれに相当する不可分命令を用いて実現される。

図１８は、tas命令を用いた排他制御処理の実装例を示す図である。メモリを占有しようとするコアプロセッサは、tas(adr)の値が１であるか否かをチェックし、１のときは、他のコアプロセッサによって占有されているため、待ちの状態になり、所定の時間毎に、そのtas(adr)の値をチェックし、０であれば、メモリを占有できる。

図１９は、排他制御が実行された時の、時系列表示の例を示す図である。図１９は、縦軸が時間軸であり、横軸は、各コアとメモリが示されている。図２０は、lock/unlock管理表の例を示す図である。

図１８のlockとunlockのプログラムを用いて、デバッグ対象プログラムP１が動作する場合を説明する。tas命令は、アドレスc番地に対して、行われるとする。
コア１が、排他制御のためのlockを行うと、イベントモニタ部によりそのlock関数の実行がイベントとして検出される。なおこのlock関数のPC値は、事前にイベントモニタ部に設定されている。
イベントモニタ部は、そのイベントをイベントコレクタ部ECに通知し、イベントコレクタ部ECは、そのイベントをカスタム部CPに通知する。

カスタム部CPは、lockが開始されたことを受け、内部状態情報収集部を介して、tas命令の対象のアドレスを調べる。また、カスタム部CPは、このアドレスに関して、バス模擬部CBの監視を開始する。

時刻t1において、カスタム部CPは、イベントコレクタ部ECを通じて、tas命令によるバスアクセスが発生したことを通知される。さらに、カスタム部CPは、このバスアクセスの結果から、コア１がlockを獲得したことを検出し、検出した情報を、排他制御に関するプロファイルとして、図２０のlock/unlock管理表２０６に記録する。

同様に、コア２のlock関数が検出され、カスタム部CPはコア２のバスアクセスを監視する。カスタム部CPは、コア１がlockを獲得しているためコア２がlockを獲得できず、すなわちlockの取得に失敗したことを、検出し、その旨を、排他制御に関するプロファイルとして、lock/unlock管理表２０６に記録する。

その後もコア２は、lock関数を実行するが、lockの取得に失敗する。
カスタム部CPは、時刻t3において、unlock関数が呼ばれたのを検出し、その旨を記録する。そして、カスタム部CPは、時刻t4において、tas命令により、０が読まれたため、コア２がlockを獲得したことを検出し、その旨をlock/unlock管理表２０６に記録する。

図１９の例では、t1からt3までの間、コア１がロックを獲得しており、コア２はその間待たなければならない。待ち時間は、オーバーヘッドでありこの待ち時間は少ないほうが望ましい。

プログラム開発装置１は、図２０のlock/unlock管理表２０６を、表示部４の画面上にそのまま表示することができる。ユーザは、画面上に表示されたlock/unlock管理表２０６を見ることによって、コア２がロックに３回失敗していることがわかる。また、コア２の待ち時間(t2〜t4)もわかる。

また、図１９のような時系列図を画面上に表示するようにしてもよい。図１９を見ることによって、ユーザは、コア２が何度もlockを試みたが、失敗していることを、視認できる。コア２が何回かのlockの試行の後にやっとlockできたので、そのような試行が無いように、あるいは少なくなるようにプログラムを作成できれば、プログラムの性能を向上させることができることを、ユーザは、図１９を一見して理解できる。

違反行番号表描画処理１４と時系列図描画処理１９とに対応する、排他制御に関する処理部が、履歴情報に基づいて、排他制御に関わる関数の実行により得られた、ロックの成否に関する情報の表示を行うロック成否表示処理部を構成する。

図２０のlock/unlock管理表２０６あるいは図１９の時系列図を見ることによって、ユーザは、SWのバグによりunlockを忘れた場合も、どのコアが原因かを特定することがより容易になる。また、SWのバグにより複数のロックを異なる順番で取得した場合、デッドロックが発生するが、ユーザは、そのような状況も把握でき、それに関わるlock関数を特定できる。

以上のように、本実施の形態のプログラム開発装置によれば、排他制御における同期状態を検出することができ、さらにその同期の獲得の状態をユーザに分かり易く表示して知らしめることができる。

なお、本実施の形態においても、lock/unlock管理表２０６に登録される情報として、lock命令のPC値等を追加することによって、第１の実施の形態と同様に、関連するソースコードの表示等も行うようにしてもよい。なお、そのソースコードの表示は、図４のソースコード描画処理１５とソースコード情報抽出処理とに対応する処理部が、排他制御に関するソースコード表示処理部を構成する。

以上のように、上述した２つの実施の形態に係るデバッグ支援装置によれば、マルチプロセッサシステムにおいて、並列実行されるプログラムのバグ等に関する情報を正確に検出することができる。

さらに、上述したデバッグ支援装置によれば、バグ等に関する情報を、プログラム開発者等に分かり易く提示することができる。

なお、上述した実施の形態では、SWによりキャッシュのコンシステシを保つシステムにおけるメモリアクセスプロトコル違反と、排他制御のデバッグとに関して説明したが、上述したシミュレータ及びバグ解析表示プログラムの構成は、他の様々な用途に応用できるものである。

また、本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明した。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。

なお、以上説明した動作を実行するプログラムは、コンピュータプログラム製品として、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶媒体に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のデバッグ支援装置を実現することができる。

本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の第１の実施の形態に係わるプログラム開発装置の構成を示す構成図である。 本発明の第１の実施の形態に係わるシミュレータの構成を示す構成図である。 本発明の第１の実施の形態に係わる、PC一覧生成プログラムの処理の流れの例を示すフローチャートである。 本発明の第１の実施の形態に係わる、プログラム開発装置のデバッグ処理関連の全体の処理の流れを説明するための図である。 本発明の第１の実施の形態に係わる、イベントモニタ部の演算模擬部の実行状態を監視する処理の流れの例を示すフローチャートである。 本発明の第１の実施の形態に係わる、イベントモニタ部のリソース間の処理内容を監視する処理の流れの例を示すフローチャートである。 本発明の第１の実施の形態に係わる、実行記録表の例を示す図である。 本発明の第１の実施の形態に係わる、状態表の例を示す図である。 本発明の第１の実施の形態に係わる、プロトコル規定表の例を示す図である。 本発明の第１の実施の形態に係わる、判定結果記録表の例を示す図である。 本発明の第１の実施の形態に係わる、バグのあるプログラム例の一部の例を示す図である。 本発明の第１の実施の形態に係わる、バグのある他のプログラムの一部の例を示す図である。 本発明の第１の実施の形態に係わる、違反行番号表の表示例を示す図である。 本発明の第１の実施の形態に係わる、ソースコード強調表示の例を示す図である。 本発明の第１の実施の形態に係わる、違反時刻一覧表表示の例を示す図である。 本発明の第１の実施の形態に係わる、違反が検出された際の関数の時系列表示の例を示す図である。 本発明の第１の実施の形態に係わる、図１６に対応する、違反を発生させた行が、以前に違反を発生させないで実行されたときの時系列表示の例を示す図である。 本発明の第２の実施の形態に係わる、tas命令を用いた排他制御処理の実装例を示す図である。 本発明の第２の実施の形態に係わる、排他制御が実行された時の、時系列表示の例を示す図である。 本発明の第２の実施の形態に係わる、lock/unlock管理表の例を示す図である。

１ プログラム開発装置、２ 本体装置、２ａ ＣＰＵ、３ 記憶部、４ 表示部、１０２ ＰＣ一覧、１０３ 実行記録表、１０４ 状態表、１０５ プロトコル規定表、１０６ 判定結果記録表、２０１ 違反行番号表表示、２０２ 違反時刻一覧表表示、２０３ 時系列図表示、２０４ ソースコード強調表示

Claims (5)

1. プログラムを並列に実行する複数のCPUの動作を模擬する複数のCPU模擬部と、
   前記複数のCPU によって共有される共有資源の模擬部と、
   各CPU模擬部と前記共有資源間において発生した所定のイベントを検出するイベントモニタ部と、
   発生した前記所定のイベントの状態が所定の条件に合致するか否かを判定し、前記所定の条件に合致したときに、前記共有資源の状態に関する履歴情報を記録する状態判定部と、
   を有することを特徴とするデバッグ支援装置。
2. 前記所定の条件は、前記共有資源に対するデータアクセスが違反とされる条件であることを特徴とする請求項１に記載のデバッグ支援装置。
3. 前記所定の条件は、前記共有資源に対する排他制御を検証するための条件であることを特徴とする請求項１に記載のデバッグ支援装置。
4. 前記履歴情報に基づいて、違反とされた前記データアクセスに関わるソースコードの表示を行うソースコード表示処理部を、さらに有することを特徴とする請求項２に記載のデバッグ支援装置。
5. 前記履歴情報に基づいて、違反とされた前記データアクセスに関わる関数の実行状態を、時系列で表示する時系列表示部を、さらに有することを特徴とする請求項２に記載のデバッグ支援装置。

Images