特許 5905904 デバッグ例外生成の制御

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5905904

(24)【登録日】2016年3月25日

(45)【発行日】2016年4月20日

(54)【発明の名称】デバッグ例外生成の制御

(51)【国際特許分類】

   G06F 11/28 20060101AFI20160407BHJP

【ＦＩ】

   G06F11/28 315A

【請求項の数】19

【全頁数】21

(21)【出願番号】特願2013-550946(P2013-550946)

(86)(22)【出願日】2012年1月19日

(65)【公表番号】特表2014-507720(P2014-507720A)

(43)【公表日】2014年3月27日

(86)【国際出願番号】GB2012050115

(87)【国際公開番号】WO2012101425

(87)【国際公開日】20120802

【審査請求日】2015年1月7日

(31)【優先権主張番号】1101490.9

(32)【優先日】2011年1月28日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】594154428

【氏名又は名称】エイアールエム リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】特許業務法人浅村特許事務所

(72)【発明者】

【氏名】ウィリアムズ、マイケル ジョン

(72)【発明者】

【氏名】グリセンスウェイト、リチャード ロイ

【審査官】 多胡 滋

(56)【参考文献】

【文献】 特開２００５−１２８７７３（ＪＰ，Ａ）

【文献】 特開２００８−０９０３９０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／２８

Ｇ０６Ｆ １１／３６

(57)【特許請求の範囲】

【請求項1】

データ処理装置であって、
プログラム命令の実行に応答してデータ処理オペレーションを行うためのデータ処理回路と、
該データ処理回路上で実行するデバッグ・ソフトウェアによって制御されるデバッグ・オペレーションを行うためのデバッグ回路と、を含み、
前記データ処理装置は、現在のデバッグ例外マスク値を保存するためのデータ記憶を含み、
前記データ処理回路は、クリティカルなコードの実行に応答してデータ記憶に、前記現在のデバッグ例外マスク値を第１の値に設定し、前記クリティカルなコードの実行の終了時に前記現在のデバッグ例外マスク値を前記第１の値を保存しないようにリセットするように構成され、
前記データ処理回路は、複数の異なるソフトウェア階層レベルに対応するプログラム命令を実行するように構成され、より高い階層レベルからアクセスできるが、より低い階層レベルからはアクセスできない少なくともいくつかのデータ記憶場所があるように、前記より高いソフトウェアの階層レベルは、前記より低いソフトウェア階層レベルに比べて大きな特権を持ち、
前記データ処理回路は、
現在、ソフトウェアが実行しているレベルと同じ階層レベルで前記デバッグ・ソフトウェアを実行する場合であって、
前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合には、デバッグ例外取得を許可し、
前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合には、前記デバッグ例外取得を許可しないように構成され、
事前定義された、現在、ソフトウェアが実行しているレベルと同じ階層レベルより高いソフトウェア階層レベルで前記デバッグ・ソフトウェアを実行する場合は、デバッグ例外取得を許可するように構成される、前記データ処理装置。

【請求項2】

前記クリティカルなコードは、その割り込みがソフトウェアの障害を起こしうる複数の命令を含む請求項１に記載のデータ処理装置。

【請求項3】

前記クリティカルなコードは、プロセッサの状態をデータ記憶に保存するためのコードおよびデータ記憶に保存した状態からプロセッサの状態を復元するためのコードを含む請求項２に記載のデータ処理装置。

【請求項4】

前記データ処理装置は、前記複数のソフトウェア階層レベルに対応した複数のデバッグ例外マスク値を保存するように構成されたデータ記憶を含み、
前記データ処理回路は、前記複数の異なるソフトウェアの階層レベルの１つに切り替えるときに、前記現在のデバッグ例外マスク値を、前記ソフトウェアの階層レベルの１つに対して保存された前記デバッグ例外マスク値に設定するように構成されている請求項１に記載のデータ処理装置。

【請求項5】

前記データ処理装置は、前記現在のデバッグ例外マスク値を保存するためのステータス記憶領域を含み、前記データ処理回路は、あるソフトウェア階層レベルから他のソフトウェア階層レベルへの切り替えに応答し、前記ある階層レベルに対する前記デバッグ例外マスク値を前記ステータス記憶領域に保存し、前記ある階層レベルに切り替わり戻るときに、前記デバッグ例外マスク値を復元する請求項１に記載のデータ処理装置。

【請求項6】

前記データ処理装置は、ステータス・インジケータを保存するためのステータス記憶領域を含み、前記ステータス・インジケータの少なくとも１つは、前記ソフトウェア階層レベルの少なくとも１つに対応するデバッグ許可のステータス・インジケータを含み、
前記データ処理回路は、前記デバッグ・ソフトウェアが、事前定義された階層レベルで、前記処理回路で実行される、前記事前定義されたソフトウェアの階層レベルで命令を実行する場合、前記事前定義されたソフトウェアの階層レベルに対する前記デバッグ許可ステータス・インジケータが事前定義された許可値に設定され、前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合、前記デバッグ例外取得を許可し、前記ステータス・インジケータが前記事前定義された許可値に設定されていないか、または前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合に前記デバッグ例外取得を許可しないように構成される請求項１に記載のデータ処理装置。

【請求項7】

前記データ処理回路は、例外に応答して、より低いソフトウェアの階層レベルから、より高い階層レベルに切り替わるとき、前記デバッグ例外マスク値を前記第１の値に設定するように構成された請求項１から６のいずれかに記載のデータ処理装置。

【請求項8】

前記データ処理回路は、例外に応答して、より低いソフトウェアの階層レベルから、より高い階層レベルに切り替わるとき、異なるタイプの例外をマスクするために複数のマスクを設定し、単独の命令の実行に応答して前記マスクのすべてをリセットするように構成された請求項１から７のいずれかに記載のデータ処理装置。

【請求項9】

前記単独の命令は、クリティカルなコードの実行が終了したことを示す命令を含む請求項８に記載のデータ処理装置。

【請求項10】

前記ソフトウェアの階層レベルは、アプリケーション・ソフトウェアを含む第１の低いレベル、オペレーティング・システム・ソフトウェアと、デバッグ・ソフトウェアを含む前記オペレーティング・システム・ソフトウェアの拡張を含む２番目のより高いレベル、ハイパーバイザのソフトウェアを含む３番目の１番高いレベルを含む、請求項１から９のいずれかに記載のデータ処理装置。

【請求項11】

前記データ処理装置は、ステータス・インジケータとさらにトラップ・インジケータを含むインジケータを保存するためのステータス記憶領域を含み、前記トラップ・インジケータは、前記デバッグ・ソフトウェアを前記ハイパーバイザ・レベルで実行することを示すトラップ値を有し、
前記データ処理回路は、前記トラップ値を有する前記トラップ・インジケータに応答して前記処理回路が現在前記ハイパーバイザ・レベルで実行していて、前記ステータス・インジケータが前記事前定義された許可値に設定されていないか、または前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合、デバッグ例外取得を許可せず、前記ステータス・インジケータが前記事前定義された許可値に設定され、しかも前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合、または前記データ処理回路が現在、前記ハイパーバイザ・レベルよりも階層的に低いレベルで実行している場合、前記ハイパーバイザ・レベルでデバッグ例外取得を許可するように構成される請求項１０に記載のデータ処理装置。

【請求項12】

前記デバッグ例外は、ウォッチポイントまたはブレークポイントの少なくとも１つを含む、請求項１から１１のいずれかに記載のデータ処理装置。

【請求項13】

前記データ処理回路は、デバッグ例外の受け取りと、前記現在のデバッグ例外マスク値が前記第１の値に設定されていることに応答して、ペンディングのデバッグ例外信号をアサートし、前記第１の値を保存しないように前記現在のデバッグ例外マスク値がクリアされていることに応答して、前記ペンディングのデバッグ例外を取得するように構成された、請求項１から１２のいずれかに記載のデータ処理装置。

【請求項14】

前記データ処理回路は、ステップ・モードの制御信号に応答してステップ・モードで実行するように構成され、この場合、プログラム内の命令は、順次のステップとして実行され、前記ステップ・モードでは、前記データ処理回路は、各前記命令の実行後に、デバッグ例外をアサートするように構成された、請求項１から１３のいずれかに記載のデータ処理装置。

【請求項15】

前記データ処理回路が前記順次命令の１つの実行中に例外を受け取ることに応答して、前記データ処理装置は、前記現在のデバッグ例外マスク値を前記第１の値に設定し、ペンディングのデバッグ例外をアサートし、前記現在のデバッグ例外マスク値が前記第１の値に設定されていないことに応答して、前記データ処理回路は、前記ペンディングのデバッグ例外を取得するように構成される、請求項１４に記載のデータ処理装置。

【請求項16】

データ処理装置内でデバッグ・オペレーションの開始を制御する方法であって、前記データ処理装置は、複数の異なるソフトウェア階層レベルに対応するプログラム命令を実行するように構成され、より高い階層レベルからアクセスできるが、より低い階層レベルからはアクセスできない少なくともいくつかのデータ記憶場所があるように、前記より高いソフトウェアの階層レベルは、前記より低いソフトウェア階層レベルに比べて大きな特権を持ち、前記方法は、
前記データ処理装置がクリティカルなコードを実行することに応答し、前記データ処理装置内のデータ記憶に現在のデバッグ例外マスク値を第１の値に設定し、および前記クリティカルなコードの実行が終了すると、前記現在のデバッグ例外マスク値を前記第１の値を保存しないように再設定するステップと、
現在、ソフトウェアが実行しているレベルと同じ階層レベルで前記デバッグ・ソフトウェアを実行する場合であって、前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合にはデバッグ例外の取得を許可し、前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合には前記デバッグ例外取得を許可しないようにするステップと、
事前定義された、現在、ソフトウェアが実行しているレベルと同じ階層レベルより高いソフトウェア階層レベルで前記デバッグ・ソフトウェアを実行する場合は、デバッグ例外取得を許可するステップとを含む、前記方法。

【請求項17】

請求項１６に記載の方法であって、
前記データ処理装置は、ステータス・インジケータを保存するためのステータス記憶領域を含み、前記ステータス・インジケータの少なくとも１つは、前記ソフトウェア階層レベルの少なくとも１つに対応したデバッグ許可ステータス・インジケータを含み、
前記事前定義されたソフトウェア階層レベルで命令を実行する場合、
前記事前定義されたソフトウェア階層レベルに対する前記デバッグ許可ステータス・インジケータが事前定義された許可値に設定されていて、前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合、前記デバッグ例外取得を許可し、
前記ステータス・インジケータが前記事前定義された許可値に設定されていないか、または前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合に前記デバッグ例外取得を許可しない、請求項１８に記載の方法。

【請求項18】

データ・プロセッサ上で実行されると、データ・プロセッサが請求項１６又は１７のいずれかに記載の方法のステップを行うように機能するコンピュータ・プログラム。

【請求項19】

データ処理装置上で実行するコンピュータ・プログラムによって提供される仮想マシンであって、前記データ処理装置は、
プログラム命令の実行に応答してデータ処理オペレーションを行うためのデータ処理回路と、
該データ処理回路上で実行するデバッグ・ソフトウェアによって制御されるデバッグ・オペレーションを行うためのデバッグ回路と、を含み、
前記データ処理装置は、現在のデバッグ例外マスク値を保存するためのデータ記憶を含み、
前記データ処理回路は、クリティカルなコードの実行に応答してデータ記憶に、前記現在のデバッグ例外マスク値を第１の値に設定し、前記クリティカルなコードの実行の終了時に前記現在のデバッグ例外マスク値を前記第１の値を保存しないようにリセットするように構成され、
前記データ処理回路は、複数の異なるソフトウェア階層レベルに対応するプログラム命令を実行するように構成され、より高い階層レベルからアクセスできるが、より低い階層レベルからはアクセスできない少なくともいくつかのデータ記憶場所があるように、前記より高いソフトウェアの階層レベルは、前記より低いソフトウェア階層レベルに比べて大きな特権を持ち、
前記データ処理回路は、
現在、ソフトウェアが実行しているレベルと同じ階層レベルで前記デバッグ・ソフトウェアを実行する場合であって、
前記現在のデバッグ例外マスク値が前記第１の値に設定されていない場合には、デバッグ例外取得を許可し、
前記現在のデバッグ例外マスク値が前記第１の値に設定されている場合には、前記デバッグ例外取得を許可しないように構成され、
事前定義された、現在、ソフトウェアが実行しているレベルと同じ階層レベルより高いソフトウェア階層レベルで前記デバッグ・ソフトウェアを実行する場合は、デバッグ例外取得を許可するように構成され、
前記仮想マシンは、前記コンピュータ・プログラムの実行により、前記データ処理装置によって提供される命令実行環境およびアプリケーション・プログラム・インターフェースと同じ命令実行環境およびアプリケーション・プログラム・インターフェースを提供する、前記仮想マシン。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ処理装置、特にデータ処理装置での診断オペレーションに関する。

【背景技術】

【0002】

ハードウェア、オペレーティング・システム、アプリケーション・プログラム、全体的なシステム設計などの開発を支援するために、データ処理システムで診断オペレーション（例、ソフトウェアとハードウェアの障害の特定と分析（デバッグ））に使用できるようにデータ処理システムに診断メカニズムを提供することが知られている。

【0003】

データ処理システムを分析する場合、外部デバッガを使用できる。外部デバッガは、システム上で実行する診断オペレーションを指定する制御信号が、ホストからシステムに渡されるように分析対象システムに接続されているホスト・システムで実行するデバッグ・プログラムを含む。

【0004】

外部デバッガでは、デバッガが外部ポートを介してターゲットに接続され、デバッグ・ハードウェアをプログラムするために使用される。プロセッサは、デバッグ・イベントにより、データ処理装置が外部デバッガによって問い合わされ、制御される特殊なデバッグ状態に入るようにする。デバッグ・イベントのデバッグ状態エントリへの変換は、ハードウェア認証インタフェースによって制御されるが、デバッグ・ハードウェアをプログラムするデバッガの機能をゲートでコントロールしない。

【0005】

または、デバッグ・モニタ・ソフトウェアがデバッグ対象のターゲットで実行される自己ホスト型デバッグ・システムであってもよい。プロセッサ上のこうしたデバッグ・ハードウェアは、デバッグ・イベントを生成するようにプログラムされ、プロセッサはデバッグ・イベントがソフトウェアによって処理されるデバッグ例外に変換されるように構成される。多くの場合、デバッグ・ソフトウェアは、特権のない、または階層が低いタスク（通常、他の特権のないアプリケーションをデバッグする場合）として実行され、特権のある、またはより高い階層のソフトウェアのエグゼクティブまたはカーネルのサービスを使用して、デバッグ・ハードウェアをプログラムし、デバッグ・イベントの通知を受け続ける。他のシナリオでは、カーネル自体がデバッグされる。

【0006】

一般に上記の２つのスキームは、ブレークポイントとウォッチポイントのレジスタなどのデバッグ・ハードウェアのほとんどを共有する。

【0007】

デバッグ・ハードウェアをプログラムするには、少なくとも以下の３つのルートがある。
１）カーネル・モードでのデバッグのためのカーネルのデバッグ・モニタによるもの
２）アプリケーションのデバッグのための特権のないデバッガ・タスクのためのカーネルによるもの
３）専用デバッグ・ポートを介した外部デバッガによるもの

【0008】

デバッグの１つの問題として、おそらく外部エージェントであるデバッグ・エージェントによるブレークポイント・レジスタのプログラミングがあり、これはオペレーティング・システムのコードを含みうるコードで例外を生成することがある。これには、リスクがあり、ソフトウェアの障害を招きうる。

【0009】

システムの障害を招きうるコード内での例外生成のリスクを減らしながら、オペレーティング・システムを含むシステムのデバッグをできるようにするのが望ましい。

【発明の概要】

【0010】

本発明の第１の態様では、以下を含むデータ処理装置を提供する。すなわち、
プログラムの命令実行に応答してデータ処理オペレーションを行うためのデータ処理回路、および
データ処理回路上で実行するデバッグ・ソフトウェアによって制御されるデバッグ・オペレーションを行うためのデバッグ回路を含む。
このデータ処理装置は、現在のデバッグの例外マスク値を保存するためのデータ記憶を含み、
データ処理回路は、クリティカルなコードの実行に応答して、現在のデバッグ例外マスク値をデータ記憶に第１の値として設定し、クリティカルなコード実行の終了に応答して、現在のデバッグ例外マスク値をその第１の値を保存しないようにリセットするように構成される。
データ処理回路は、複数の異なるソフトウェア階層レベルに対応するプログラム命令を実行するように構成される。この場合、より高いソフトウェア階層レベルは、より低いソフトウェア階層レベルに比べて大きな特権を持ち、より高い階層レベルからアクセスできるが、より低い階層レベルからはアクセスできない少なくともいくつかのデータ記憶域の場所があるようにする。
この場合、データ処理回路は、現在、ソフトウェアが実行しているレベルと同じ階層レベルで前記デバッグ・ソフトウェアを実行する場合に、現在のデバッグ例外マスク値が第１の値に設定されていなければデバッグ例外取得を許可し、現在のデバッグ例外マスク値が第１の値に設定されていればデバッグ例外取得を許可しないように構成され、事前定義されたより高いソフトウェア階層レベルで前記デバッグ・ソフトウェアを実行する場合は、デバッグ例外取得を許可する。

【0011】

本発明では、いくつかのコードの実行はパフォーマンスとシステムが正しく挙動するうえでクリティカルであり、こうしたコードに割り込みすると、システムの障害をほぼ招きうることを認識している。処理中にどの時点であっても非同期の割り込みが起こりうるが、これは一般的に現在実行中の命令ストリームの命令とは独立して発生し、しばらくペンディングになることが許容され、処理中に適切なポイントに到達した場合にシステムはこうした例外を取得するように構成されていることも認識している。命令ストリーム内の命令に応答して同期例外が発生するが、これは従来、ただちに取得される。

【0012】

同期例外がクリティカルなコードの実行中に発生すると問題となりうる。一般的に、データ処理システムは、クリティカルなコードの間は、データのアボートなどの同期例外を生成しうるメモリ領域へのアクセスは行われないようにし、こうした不測の事態に対して防護する。しかし、本発明では、デバッグ回路によって生成されうる他の同期例外があり、これらは通常の処理オペレーションの制御の範囲外であり、不測の例外として発生することを認識している。こうした例外が取得されないことが重要であり、従って本発明のシステムでは、クリティカルなコードの実行に応答して、プロセッサがマスク値を設定し、このマスク値はクリティカルなコードの実行中に受け取ったデバッグ例外の取得を禁止するために使用される。クリティカルなコードの実行の終了時に、マスク値はリセットされ、例外取得を禁止した値を保持しないようにする。従って、こうした単純ではあるが、簡潔な方法によりクリティカルなコードは、デバッグ中に同期的に生成される例外から保護される。

【0013】

さらに、多くの処理装置は異なるソフトウェア階層レベルでデータを処理し、特定のメモリ領域とシステム・レジスタへのアクセスは低階層レベルからは禁止され、高階層レベルからは許可される。デバッグ例外マスク値は、現在ソフトウェアが実行しているレベルと同じ階層ではデバッグ例外取得を禁止するために使用可能であり、こうした例外はリエントラント可能な例外と呼ばれることが多い。従って、デバッグ・ソフトウェアが同じ階層で実行することを制御信号が示している場合に、特定の階層レベルで命令を処理する場合、デバッグ例外マスク値を使用してその例外が取得されることを防ぐことができる。これはそのレベルでクリティカルなコードを現在実行中に例外取得を禁止するために使用できる。クリティカルなコードを実行している場合、プロセッサが正しく挙動するために不可欠な値を保存しているレジスタが上書きされる可能性があるため、例外がそのレベルで取得されないことが重要である。しかし、制御信号が、現在コードを実行している階層とは異なる階層レベルで例外が取得されることを示している場合（多くの実施形態では、例外取得はより高い階層レベルでのみ許可される）、この他の階層レベルは独自の割り込みレジスタを持っているため、より低い階層レベルでのクリティカルなコードの割り込みは許容できる。これは、重要な情報を保存しているレジスタが上書きされないためである。こうして、本発明の実施形態では、システムを細分化し、例外取得によってソフトウェアの障害を起こしうる階層レベルでのみ例外取得を禁止する。

【0014】

ある実施形態では、デバッグ回路はデバッグ例外を取得することを示す信号をデータ処理回路に送り、処理回路は現在のデバッグ・マスク値に応じて例外の取得を禁止または許可する。他の実施形態では、デバッグ・マスク値が設定されている場合、処理回路に制御信号を送ることをアサートしないことにより、現在のマスク値に応答するのはデバッグ回路自体である。

【0015】

実行されるデバッグ・オペレーションは、外部ホストで実行するデバッグ・ソフトウェアによって制御される場合があるが、ある実施形態では、デバッグ回路は、データ処理回路上で実行するソフトウェアによって制御されるデバッグ・オペレーションを行う。

【0016】

クリティカルなコードは、多数ありうるが、ある実施形態では、その割り込みがソフトウェアの障害を起こしうる複数の命令を含む。

【0017】

異なる種類のコードを実行する場合、デバッグ回路から例外取得を禁止するようにデータ処理装置を構成しうるが、例外取得によってソフトウェアの障害を起こしうる場合にコード実行中の取得を禁止すると有用である。こうしたコードを実行する場合に、例外の取得を禁止することが重要であることは明らかである。

【0018】

こうしたコードは、様々なものを含む。例えば、システムを構成するレジスタ値を保存または復元するコード、システム・レジスタの割り込みを確認、無効化、または再有効化するコード、プロセッサの状態をデータ記憶に保存するためのコード、またはそのデータ記憶から状態を復元するコードを含む場合がある。明らかに、プロセッサの状態を正しく保存し、正しく復元することは重要である。従って、こうしたコードの割り込みを回避するのが最良である。

【0019】

ある実施形態では、データ処理装置は、データ記憶を含む。データ記憶は、複数の異なるソフトウェア階層レベルに対応した複数のデバッグ例外マスク値を保存するように構成される。データ処理回路は、複数のソフトウェア階層レベルの１つに切り替える場合に、現在のデバッグ例外マスク値を、その複数のソフトウェア階層レベルの１つに対して保存されているデバッグ例外マスク値の値に設定するように構成される。

【0020】

ある実施形態では、処理装置は異なるソフトウェア階層レベルに対するデバッグ例外マスク値を保存するための記憶装置を含む。こうした値は、当該レベルでプログラムの命令の実行に切り替える際に、そのデバッグ例外マスク値の現在の値を設定するために使用される。異なる階層レベルに対して異なるマスク値を保存することで、高度な細分性と制御を実現する。

【0021】

ある実施形態では、データ処理装置は、現在のデバッグ例外マスク値を保存するためのステータス記憶領域を含む。データ処理回路は、ソフトウェアのある階層レベルから異なる階層レベルへの切り替えに応答し、その階層レベルに対してデバッグ例外マスク値をステータス記憶領域に保存し、ある階層レベルに切り替わって戻るときに、そのデバッグ例外マスク値を復元する。

【0022】

または、異なる階層レベルに対して異なるマスク値を保存するのではなく、デバッグ例外マスク値は、階層レベルを離れるときにステータス記憶領域に保存してもよく、デバッグ例外があるレベルでマスクされ、そのレベルに戻るときに再度マスクされるように、この値は、そのレベルに戻る際に、デバッグ例外マスク記憶位置に復元されてもよい。

【0023】

ある実施形態では、データ処理装置は、ステータス・インジケータを保存するためのステータス記憶領域を含む。このステータス・インジケータの少なくとも１つは、ソフトウェア階層レベルの１つに対応したデバッグ許可ステータス・インジケータを含む。データ処理回路は、事前定義されたソフトウェア階層レベルで命令を実行し、デバッグ・ソフトウェアが処理回路でその階層レベルで実行する場合に以下を行うように構成される。すなわち、その事前定義されたソフトウェア階層レベルに対するデバッグ許可ステータス・インジケータが事前定義された許可値に設定されていて、現在のデバッグ例外マスク値が第１の値に設定されていない場合に例外の取得を許可する。ステータス・インジケータが事前定義された許可値に設定されていないか、または現在のデバッグ例外マスク値がその第１の値に設定されている場合に、その例外の取得を許可しない。

【0024】

本技術では、異なる階層レベルでのシステムのデバッグは、おそらくオペレーティング・システムのコードなどの重要なコードが実行されているより高い階層レベル内での例外のトリガーにつながる可能性があり、こうしたコードの割り込みは望ましくない、ことを認識している。例えば、プロセッサで実行しているオペレーティング・システムがデバッグできるようにシステムがセットアップされている場合、通常のオペレーション中には、オペレーティング・システムで例外の生成が認められないように、ある時点ではデバッグを禁止できることが望ましい場合がある。こうした例外生成は、オペレーティング・システムの障害を招き、セキュリティ上の問題を発生しうる。従って、本発明の実施形態では、特定の階層レベルでデバッグを許可または禁止するように設定できるステータス・インジケータを提供する。このようにして、ステータス・インジケータを設定すると、例えば、システムがテスト中である場合、全階層レベルのデバッグを許可するが、システムが出荷されると、より高い階層レベルでのデバッグを禁止することができる。つまり、システムで実行されるアプリケーションは何でもデバッグできるが、出荷前に完全にテストされたオペレーティング・システムでのデバッグ例外生成は認められない。

【0025】

これは、例えば、ブレークポイントのレジスタを設定する外部手段がある場合、有用である。こうした場合、外部エージェントは、オペレーティング・システム内で例外を発生しうる。こうした例外は、当該処理システムの制御下にはなく、深刻なエラーを発生する可能性があり、従って回避するのが最良である。

【0026】

ある実施形態では、事前定義されたソフトウェア階層レベルで命令を実行し、デバッグ・ソフトウェアを事前定義されたより高いソフトウェア階層レベルで実行する場合、例外を取得することを示すデバッグ回路からの制御信号の受信に応答して、データ処理回路は例外取得を許可するように構成される。

【0027】

現在、命令を実行しているレベルよりも高い事前定義されたソフトウェア階層レベルでデバッグ・ソフトウェアを実行することを示すデバッグ例外を取得する場合、こうした例外の取得は常に許可される。こうしたより高いレベルは、割り込み値を保存するための独自のレジスタを持っているためである。従って、より低いレベルでクリティカルなコードを割り込みすることになっても、プロセッサの状態が破損されることはないであろう。

【0028】

ある実施形態では、データ処理回路は、例外に応答してより低いソフトウェア階層レベルからより高いソフトウェア階層レベルに切り替える場合、現在のデバッグ例外マスク値を第１の値に設定するように構成される。

【0029】

例外を取得する際にクリティカルなコードが実行されており、従って、このレベルでさらにデバッグ例外を取得することによってクリティカルなコードが割り込みされないように処理装置がマスク値を設定するのが望ましい。

【0030】

デバッグ例外は、多くの形式をとりうるが、レジスタに保存されるアドレスであるウォッチポイントの場合がある。この場合、このアドレスへのアクセス、またはアクセスの試みは、デバッグ制御信号のアサートをトリガーする。または、これもデバッグ・レジスタに保存されるアドレスであるブレークポイントである場合がある。この場合、このアドレスを有する命令を実行または実行の試みは、デバッグ制御信号のアサートをトリガーする。

【0031】

ある実施形態では、データ処理回路は、デバッグ例外を取得することデバッグ例外のマスク値が第１の値に設定されていることを示すデバッグ回路からの制御信号の受信に応答して、ペンディングしているデバッグ例外をアサートし、第１の値を保存しないようにマスクがクリアされることに応答して、ペンディングしているデバッグ例外を取得するように構成される。

【0032】

前述のように、デバッグ例外は同期的例外であり、命令の実行に応答して発生する。マスク値が、例外がトリガーできないことを示す第１の値に設定されている場合、実施形態によっては、ペンディングのデバッグ例外信号が生成され、マスクがクリアされ、第１の値が保存されなくなった場合、デバッグ許可ステータス・インジケータが許可を示していることを前提にペンディングのデバッグ例外を取得可能になる。デバッグ例外は、プログラムをデバッグしている者が、プロセッサの状態を知りたいことを示しているため、これは望ましい。従って、ソフトウェア障害の原因になりうるため、ただちに応答することは禁止されているが、後で応答することは許可され、有用な情報を生成しうる。

【0033】

ある実施形態では、データ処理回路は、ステップ・モードの制御信号に応答して、ステップ・モードで実行するように構成される。この場合、プログラム内の命令は順次ステップとして実行され、このステップ・モードでは、データ処理回路は、各順次命令の実行後にデバッグ例外をアサートするように構成される。

【0034】

本発明の実施形態がサポートするデバッグ・モードとして考えられるものは、ステップ・モードがある。この場合、各命令が実行され、その後にデバッグ例外が取得される。こうすることで、プログラムはステップをたどり、各命令の実行後に、レジスタ内の値またはプロセッサの他の状態を照会できるように、デバッグ・ソフトウェアに対して制御が与えられる。

【0035】

ある実施形態では、データ処理回路が順次命令の１つを実行中に例外を受け取ることに応答して、データ処理装置は、現在のデバッグ例外マスク値を第１の値に設定し、ペンディングのデバッグ例外をアサートするように構成される。また、現在のデバッグ例外マスク値が第１の値に設定されていないことに応答して、データ処理回路はペンディングのデバッグ例外を取得するように構成される。

【0036】

ステップ・モードで、順次命令の実行中に例外が発生すると、ペンディングのデバッグ例外とデバッグ例外マスクの使用によって、例外でクリティカルなコードの実行中にデバッグ例外が確実に取得されないようにできるが、クリティカルなコードの実行が完了したときに、マスクがクリアされるとデバッグ例外が取得される。

【0037】

ある実施形態では、データ処理回路は、例外に応答し、より低い階層からより高いソフトウェアの階層レベルに切り替える場合に、異なるタイプの例外をマスクするために複数のマスクを設定し、単独の命令の実行に応答してマスクのすべてをリセットするように構成される。

【0038】

デバッグ例外は、マスクのリセットに加えてクリティカルなコードの実行中に他の非同期の例外の取得をマスクするように他のマスクが設定される場合がある。この場合、クリティカルなコードの実行の完了が、単独の命令によって示されると、こうした命令の実行により、すべてのマスクのクリアがトリガーされうる。このようにして、他のマスクと合わせてクリアされるため、デバッグのマスクをクリアするために追加のコードを必要としない。

【0039】

ある実施形態では、単独の命令は、クリティカルなコードの実行終了を示す命令を含む。

【0040】

マスクのサブセットは、クリアされるか、または実際は１つの命令に設定されるかであることに注意されたい。処理装置の異なる階層レベルは、多くのものを含みうるが、ある実施形態では、アプリケーション・ソフトウェアが実行される第１の低いレベル、オペレーティング・システムのソフトウェアが実行される第２のより高いレベル、およびハイパーバイザ・ソフトウェアが実行される第３の最も高いレベルがある。

【0041】

ある実施形態では、データ処理装置は、ステータス・インジケータとさらにトラップ・インジケータを含むインジケータを保存するためのステータス記憶領域を含む。このトラップ・インジケータは、デバッグ・ソフトウェアがハイパーバイザ・レベルで実行されることを示すトラップ値を持つ。データ処理回路は、トラップ値を持つトラップ・インジケータに応答して、処理回路が現在ハイパーバイザ・レベルで実行し、ステータス・インジケータが事前定義された許可値に設定されていないか、現在のデバッグ例外マスク値が第１の値に設定されている場合、デバッグ例外の取得を許可せず、ステータス・インジケータが事前定義された許可値に設定されていて、しかも現在のデバッグ例外マスク値が第１の値に設定されていないか、またはデータ処理回路がハイパーバイザ・レベルよりも低い階層レベルで現在実行している場合、ハイパーバイザ・レベルでデバッグ例外取得を許可するように構成される。

【0042】

細分性を実現する１つの方法として、現在の階層レベルで、リエントラントのデバッグ例外を許可または許可しない単独のステータス・インジケータを持つこと、および現在のレベルが階層的にハイパーバイザ・レベルよりも低いことを前提として例外をハイパーバイザ・レベルにトラップするさらなるトラップ・インジケータを持つことがある。図１の実施形態など、多くの場合、ハイパーバイザ・レベルよりも高いレベルはないが、そうしたレベルがあったとして、処理回路がそのレベルで稼働している場合、トラップ値は例外をハイパーバイザ・レベルにトラップしないが、これは、例外は、より低い階層レベルでは取得できないためである。前述のように、例外は常により高いレベルで取得できる。そのため、例外がハイパーバイザ・レベルよりも下のレベルで発生した場合、取得可能となる。処理回路がハイパーバイザ・レベルで稼働していれば、ステータス・インジケータが例外取得を許可していること、例外がマスクされていないことを前提に、例外は取得される。

【0043】

本発明の第２の態様では、データ処理装置内のデバッグ・オペレーションの開始を制御する方法を提供する。データ処理装置は、複数の異なるソフトウェア階層レベルに対応するプログラム命令を実行するように構成され、より高い階層レベルからアクセスできるが、より低い階層レベルからはアクセスできない少なくともいくつかのデータ記憶場所があるように、前記より高いソフトウェアの階層レベルは、前記より低いソフトウェア階層レベルに比べて大きな特権を持つ。この方法は、以下のステップを含む。
データ処理装置がクリティカルなコードを実行することに応答して、現在のデバッグ例外マスク値をデータ処理装置内のデータ記憶の第１の値に設定し、クリティカルなコードの実行が終了すると、現在のデバッグ例外マスク値を第１の値を保存しないようにリセットする。
現在、ソフトウェアが実行しているレベルと同じ階層レベルで前記デバッグ・ソフトウェアを実行する場合は、現在のデバッグ例外マスク値が、第１の値に設定されていなければ、デバッグ例外の取得を許可し、現在のデバッグ例外マスク値が第１の値に設定されていれば、デバッグ例外の取得を許可しない。
事前定義されたより高いソフトウェア階層レベルで前記デバッグ・ソフトウェアを実行する場合は、デバッグ例外取得を許可する。

【0044】

本発明の第３の態様では、コンピュータ・プログラムを保存しているコンピュータ・プログラム製品を提供する。このコンピュータ・プログラムは、データ・プロセッサで実行されると、データ・プロセッサが本発明の第２の態様に従った方法のステップを実行するように制御するように動作可能である。

【0045】

本発明の第４の態様は、データ処理装置で実行するコンピュータ・プログラムによって提供される仮想マシンがある。この仮想マシンは、本発明の第１の態様のデータ処理装置の命令実行環境を実現する。

【0047】

上記および本発明のその他の目的、機能、特徴は、添付の図面と関連付けて読まれる例示的実施形態の以下の詳細な説明から明らかになるであろう。

【図面の簡単な説明】

【0048】

【図1】本発明の一実施形態のデータ処理装置のソフトウェア階層レベルを示す図である。

【図2】ホストのデバッガに接続されたデータ処理装置を示す図である。

【図3a】ＫＤＥが０に設定された状態で、ＥＬ０レベルからＥＬ１レベルでの例外取得を示す図である。

【図3b】ＫＤＥが１に設定された状態で、ＥＬ０レベルからＥＬ１レベルでの例外取得、およびデバッグ・イベントに応答したリエントラントの例外取得を示す図である。

【図4】ＫＤＥが１に設定された状態で、ＥＬ０レベルからＥＬ１レベルでの例外取得、およびデバッグ・マスクが設定されている間に発生するデバッグ・イベントに応答したリエントラントの例外取得を示す図である。

【図5】ソフトウェアのステップのデバッグ・オペレーション中に生じる状態を示す状態図である。

【図6】割り込みを取得したクリティカルなコードを実行する場合に起こるステップを示す流れ図である。

【図7】図６に類似した流れ図であるが、この場合、複数の例外が起こりうる。

【図8】本発明の一実施形態の仮想マシンの実装を示す図である。

【発明を実施するための形態】

【0049】

図１は、本発明の実施形態のデータ処理装置の様々なソフトウェア階層レベルを表している。この実施形態では、ハイパーバイザを含む最高の階層レベル、ＥＬ２がある。この中には、デバッグ・サービスを含む場合がある。この場合、デバッガはハイパーバイザ・アプリケーションとして実行し、このハイパーバイザは、デバッグ・ハードウェアのプログラミングを行う。

【0050】

この次のレベルは、ＥＬ１レベルであり、ゲストのオペレーティング・システムが実行される。これらのレベルの中にも、デバッグ・サービスを含む場合がある。繰り返しになるが、こうしたデバッグ・サービスはデバッグ・ハードウェアのプログラミングを行う。

【0051】

３つ目のレベルは、アプリケーションが実行される最下層のＥＬ０レベルである。こうしたアプリケーションの１つがデバッグ・アプリケーションの場合がある。

【0052】

図２は、本発明の実施形態のデータ処理装置である。本実施形態のデータ処理装置１０は、ホスト・デバッガ２０に接続される。ホスト・デバッガは、入力１２を介してデータ処理装置１０と通信し、デバッグ命令をデータ処理装置１０に送信し、データ処理装置１０から診断データを受信する。データ処理装置１０は、命令のストリームを実行するためのプロセッサ３０を含む。また、データ処理装置１０は、デバッグ・ハードウェア４０、４７、４８も含む。こうしたデバッグ・ハードウェア４０、４７、４８には、データ記憶４０とレジスタ・バンク４２内のレジスタ４７と４８を含む。データ記憶４０は、デバッグ例外を、取得可能か否かを示すステータス・インジケータとマスク値を保存するためのものである。レジスタ４７と４８は、デバッグ例外を取得すべき場所を示すブレークポイントとウォッチポイントの値を保存するためのものである。

【0053】

マスク値に関して、それぞれ特定の階層レベルに関するいくつかのマスク値が保存され、そのレベルで取得されるデバッグ例外のマスクとして機能する。こうした値の１つは、現在のデバッグ・マスク値またはマスク・フラグであり、設定されると現在のソフトウェア階層レベルで取得されるリエントラントの例外であるデバッグ例外を禁止する。このマスク・フラグは、プロセッサの状態の一部であり、割り込みに応答してこの状態を保存する場合、この値も保存される。このマスク値のオペレーションについては後述する。

【0054】

割り込みまたはその他の例外が取得される場合、プロセッサの状態を保存するために少なくとも１つのデータ記憶４６がある。前述のように、データ記憶４６に保存されるプロセッサの状態には、プロセッサがソフトウェアの階層レベルを変更する場合、現在のデバッグ・マスク値またはマスクのフラグが含まれうる。

【0055】

各ソフトウェア階層レベルに対して１つずつ、いくつかのデータ記憶４６が存在する場合がある。例えば、ＥＬ１で割り込みを取得する場合、プロセッサの現在の状態は、ＥＬ１レベルに対してデータ記憶４６に保存され、ＥＬ１で割り込みされた処理に切り替わって戻る場合、その状態はＥＬ１に対するデータ記憶４６から復元される。デバッグ・マスクが、ＥＬ１に対して設定されている場合、この値はデータ記憶に保存され、その状態が復元されるときに再度設定されるであろう。

【0056】

データ記憶４６は、例外を取得する場合、プロセッサの状態を保存する目的専用であってもよいし、またはデータ・メモリなどのより汎用的なデータ記憶の一部であってもよい。

【0057】

ホスト・デバッガ２０は、デバッグ・ハードウェア４０、４７、４８自体をプログラムしてもよいし、ホスト・デバッガ２０内の個別のプロセッサ上でソフトウェアのデバッグを実行してもよい。または、プロセッサ３０は、ソフトウェアの階層レベルの１つの中にデバッグ・サービスを持ってもよく、ホスト・デバッガからの信号に応答して、これらを使用してデバッグ・ハードウェアをプログラムしてもよい。さらに、ホスト・デバッガ２０自体は、プロセッサ３０で実行するプログラムであってもよい。

【0058】

ブレークポイント値とウォッチポイント値は、レジスタ４７と４８で設定される。実行されている命令のアドレスとして現れるブレークポイント・レジスタのアドレスに応答して、またはアクセスされているデータの場所のアドレスとして現れるウォッチポイントのレジスタのアドレスに応答して、デバッグ例外が生成される。こうした例外は、デバッグ・ソフトウェアがプロセッサを制御し、この時点でのプロセッサの状態についてのデバッガ情報を伝えるためにユーザと通信するようにする。

【0059】

前述のように、コード実行中の例外取得が望ましくない状況があり、従って本発明の実施形態では、こうしたデバッグ例外取得を禁止することが適切な場合に、禁止するためのメカニズムを提供する。こうした制御の細分性は、様々な方法で実現できる。例えば、オペレーティング・システム実行中の例外取得は望ましくないかもしれないが、出荷前にそうしたオペレーティング・システムをデバッグできることは望ましいであろう。従って、ＥＬ１レベルでオペレーティング・システム内のカーネル・デバッガを提供するが、禁止フラグ、ＫＤＥビットの使用でこのデバッガが生成する例外取得を禁止できるようにするのは有用であろう。

【0060】

従って、データ記憶４０に保存されているＫＤＥビットがクリアされると、ＴＤＥビットが設定されない限り、こうしたアドレスがＥＬ１レベルからアクセスされる場合、例外が生成されないようにブレークポイントやウォッチポイントは無効になる。これについては後述する。このように、適宜、カーネルに例外を生成できないように、こうしたデバッグを無効にする機能と共にオペレーティング・システムをデバッグする機能が提供されている。従って、出荷前にシステムを完全にデバッグできるが、出荷後は、例えば、ＫＤＥビットを永久にクリアし、カーネルのデバッグを許可しないようにすることが可能である。

【0061】

データ記憶４０に保存されているＴＤＥビットもあり、このビットはＥＬ２レベルでハイパーバイザにマッチするブレークポイントまたはウォッチポイントで生成された例外をトラップし、生成された例外がハイパーバイザ内で取得され、サービスされるようにする。この例では、データ記憶４０は、レジスタ４２とは異なる記憶として示されているが、こうしたフラグは、レジスタ・バンク４２内のレジスタ内に保存されうる。

【0062】

ＫＤＥビットは、ＥＬ１に関連して上記で説明されているが、ＥＬ２レベルでデバッグ例外取得を禁止するＥＬ２レベルに対する別個のＫＤＥビットが存在しうることに注意されたい。

【0063】

または、実施形態によっては、ＴＤＥビットが設定されていない場合に、ＥＬ１レベルに関連する単独のＫＤＥビットがある。ＴＤＥビットが設定されると、デバッグ例外はハイパーバイザ・レベルにトラップされ、ある実施形態では、ＫＤＥビットがＥＬ２レベルに関連することを示すように設定される場合、ＴＤＥビットを使用する。ＴＤＥビットは、デバッグ例外をハイパーバイザ・レベルでトラップするように設定されているため、ＥＬ１レベルで例外が発生すると、より高い階層レベルで取得されるため、その例外は常に取得できる。従って、ＥＬ１レベル（ＴＤＥが設定されていない場合）とＥＬ２レベル（ＴＤＥが設定されている場合）の両方で単独のＫＤＥビットを使用すると便利である。

【0064】

こうして、ＴＤＥビットとＫＤＥビットと合わせて、ＥＬ１レベルとＥＬ２レベルでリエントラント例外の取得を禁止または許可することができる。

【0065】

カーネルのデバッグを許可するか否かの細分性を実現することに加えて、特定のコード実行時にデバッグ例外の取得を禁止する機能も備えうる。これは、現在のデバッグ・マスク値またはマスク・フラグ４３によって実現する。このマスク・フラグは、特定のコードを実行するときに、プロセッサ３０によって設定される。従って、プロセッサがＥＬ１レベルでコードを実行していて、それがクリティカルなコードの場合、コードの割り込みはソフトウェアの障害を招くことがあり、プロセッサ３０がデバッグのマスク・フラグを設定する。その後、このマスク・フラグが取得を禁止しているため、デバッグ例外が生成されても、このレベルでは取得できない。

【0066】

ある実施形態では、これは例外が決して取得されないことを意味しうるが、他の実施形態では、ペンディングのフラグ４４が設定される場合がある。この場合、プロセッサがクリティカルなコードの実行を終了後に、おそらくソフトウェアの命令によってマスク・フラグが再設定されると、ペンディングしている例外を取得できる。

【0067】

これは、図３ａ、３ｂ、および４に詳しく示されている。こうした図では、アプリケーションは、そのアプリケーションのＥＬ０レベルで実行しており、例外が受け取られる（この例外は、デバッグ例外だけでなく、あらゆるタイプの例外でありうる）。次にプロセッサは、ＥＬ１レベルに移動し、その例外を処理する。最初に、このレベルで実行を開始する場合、クリティカルなコードが実行され、これにより、そのアプリケーションに戻るときにその状態が復元できるようにプロセッサの状態が保存される。このクリティカルなコードの実行中に、保存中の状態が上書きされないように、このレベルでさらに例外が取得されないようにすることが重要である。従って、この時点でデバッグ・マスク・フラグ、ＣＰＳＲ．Ｄが１に設定される。システムの例外ハンドラが次に実行され、これにより、例外を処理する。この処理のある時点で、システム例外ハンドラが、プロセッサの状態の保存を完了する。これは、ソフトウェアがこのクリティカルなコード領域を離れることが可能になり、ＣＰＳＲ．Ｄフラグが０に設定されることを意味する。システム例外ハンドラが例外の処理を完了すると、割り込みしたアプリケーションの処理に戻らなければならないと判断し、従って、さらにクリティカルなコード領域に入り、元の例外の時点でのプロセッサの状態を復元する一方で、デバッグ・マスク・フラグ、ＣＰＳＲ．Ｄが再度１に設定される。

【0068】

図３ａでは、ＫＤＥビットは０に設定される。従って、デバッグ例外取得はＥＬ１レベルで許可されず、すべてのブレークポイントとウォッチポイントが無効になる。従って、ＥＬ１での処理中は、クリティカル領域、または残りのシステムの例外ハンドラでもデバッグ例外は受け取られない。

【0069】

図３ｂでは、ＫＤＥビットは１に設定される。従って、ＥＬ１レベルでのデバッグ例外取得は許可されるが、クリティカルなコード領域内では許可されない。こうしたリエントラントデバッグ例外は、ブレークポイントに応答して受け取られ、この時点ではデバッグ・マスク・フラグ、ＣＰＳＲ．Ｄは０、ＫＤＥ＝１であり、このデバッグ例外は取得され、カーネルがブレークポイント・ハンドラを使用して例外を処理する。これが完了すると、例外の戻りがあり、カーネルはシステム例外ハンドラの処理を継続する。システムの例外処理が完了すると、デバッグ・マスク・フラグが１に設定されるコードのクリティカル領域に入り、このポイントでデバッグ例外が受け取られても無視される。

【0070】

図４は、本発明の実施形態の例外処理のさらなる例を示している。再度、図３ｂのように、ＫＤＥビットが設定され、そのアプリケーション・レベルで例外が受け取られ、取得されると、処理はＥＬ１レベルに切り替わる。プロセッサの状態を保存するために、クリティカルなコードが最初に実行され、デバッグ・マスク・フラグ、ＣＰＳＲ．Ｄが１に設定される。この間、ウォッチポイントのデバッグ・イベントが発生し、デバッグ・マスク・フラグが設定されているため、これは取得できない。しかし、このＫＤＥが設定されているため、本実施形態では、このウォッチポイントを無視するのではなく、ペンディングのデバッグ例外フラグが１に設定される。従って、クリティカルなコードの実行が終了すると、ソフトウェアがデバッグ・マスク・フラグを０にリセットし、ペンディングのデバッグ例外フラグは、ペンディングのデバッグ例外があることをプロセッサに示し、従って、この時点で取得され、カーネルがウォッチポイントのハンドラを実行し、その例外を処理する。

【0071】

ペンディングのデバッグ例外が取得されるとただちに、プロセッサがペンディングのデバッグ・マスク・フラグの現在の値、０を保存し、次にそれ（ＣＰＳＲ．Ｄ）を１に設定する。デバッグ例外ハンドラ、この場合、ウォッチポイントのハンドラが続いて実行され、完了すると、デバッグ・マスク・フラグに対して保存されていた値が復元される。この場合、ＣＰＳＲ．Ｄが０にリセットされる。この時点で、システムのコール・ハンドラを実行し、完了すると、ソフトウェアは例外のリターン・コードに入る。これは、クリティカルなコードであり、従って、このコードの実行の継続中、デバッグ例外フラグＣＰＳＲ．Ｄが再び１に設定される。

【0072】

前述の例では、ＫＤＥビットはＥＬ１について説明したが、ＥＬ２レベルに関するＫＤＥビットもありうる。ＫＤＥビットが特定レベルでクリアされると、そのレベルでソフトウェアのデバッグ・イベントが無効になる。実施形態によっては、ＫＤＥビットがそのレベルに対してクリアされても、有効であるデバッグ・イベントがあるであろう。例えば、ソフトウェアのブレークポイント命令は、デバッグ例外を生成する命令のタイプである。ハードウェアのブレークポイント・レジスタ４２が利用できない場合、ある場所でブレークポイントを設定する手段として、デバッガが実際のプログラム命令を、ソフトウェアのブレークポイント命令と置き換える。オリジナルのプログラム命令は存在しなくなっているため、ＫＤＥビットがクリアされても、こうしたデバッグ命令を無視するのは安全ではない。

【0073】

ＴＤＥビットが設定されている場合、ＥＬ０レベルまたはＥＬ１レベルのいずれかからのソフトウェアのデバッグ・イベントがＥＬ２レベルにトラップされる。従って、ＴＤＥビットが設定される場合、ＥＬ０またはＥＬ１で発生するデバッグ・イベントは、ＥＬ１レベルに対するＫＤＥビットによる影響を受けず、ＥＬ２レベルで取得されるであろう。

【0074】

ある実施形態では、ＴＤＥビットがクリアである場合、ＥＬ１レベルでデバッグ例外に影響を与え、ＴＤＥビットが設定されている場合にＥＬ２レベルでデバッグ例外に影響を及ぼす単独のＫＤＥビットがある。

【0075】

ある実施形態では、単純なソフトウェアのステップの状態機械を実行するようにデバッガが構成される。この場合、各命令実行後に、プロセッサが停止し、状態が分析される。ソフトウェアのステップはソフトウェアの制御下にあるため、ソフトウェアのステップ・デバッガが現在の例外レベルで有効化または無効化するように、ステッピングはグローバルなデバッグが有効にしたコントロールによっても制御される。

【0076】

図５は、ソフトウェアのステップのデバッグ・オペレーション例の間に発生する状態を示す状態図である。この図では、以下の３種類のコードがある。「デバッガ」は、デバッガ・コード自体を含み、例えば、ＥＬ１で実行するコードである。「デバッグ対象」はデバッグされているコードを含み、例えば、ＥＬ０で実行するコードであり、ＫＤＥが設定されている場合、クリティカルなコード以外で、ＥＬ１で実行するコードである。「クリティカルなコード」は、デバッグ例外によって割り込みされてはいけないコードを含み、これはデバッグ・マスク・フラグＣＰＳＲ．Ｄが設定された状態でデバッガ（ＥＬ１）と同じレベルで実行されるコードである。

【0077】

ステップ・プロセスを開始する前に、ソフトウェアのステップ状態機械は、無効な状態であり、デバッガのコードが実行している。デバッガは、モニタ・デバッグ・ステータスでシングル・ステップの制御フラグを設定し、ＥＬ１レベルから制御レジスタ（ＭＤＳＣＲ＿ＥＬ１）を設定することにより、ステッピングのためにプロセスをセットアップする。次にデバッガは例外リターン命令を実行し、デバッグ対象コードにジャンプする。デバッグ対象コードで、シングル・ステップのデバッグ・イベントがアクティブであるが、例外はまだペンディングされていない。

【0078】

次に、プロセッサが命令を実行し、これは通常、ソフトウェアのステップの状態機械をアクティブなペンディング状態に移動させる。この時点で、ペンディングのソフトウェアのステップのデバッグ例外が取得され、実行はデバッガに戻り、シングル・ステップが完了する。

【0079】

しかし、命令実行中に他の例外があると、これを取得し、クリティカルなコードが最初に実行されているため、プロセッサはデバッグ・マスク・フラグＣＰＳＲ．Ｄを設定する。これは、ペンディングのシングル・ステップのデバッグ例外がマスクされていることを意味する。このデバッグ例外は、クリティカルなコードが完了し、ＣＰＳＲ．Ｄフラグがクリアされている場合に限り取得可能である。しかし、例外ハンドラが、ＣＰＳＲ．Ｄフラグをクリアしない場合、デバッグ対象コードに戻る。例外ハンドラがステップされていた命令の再実行に戻る場合、ペンディングのシングル・ステップのデバッグ例外は、クリアされる。

【0080】

デバッグ・マスク・フラグとＴＤＥビット、ＫＤＥビットで達成できる細分性が以下の表にいくつかの事例として示されている。この表は、こうしたフラグのいくつかの構成によってデバッグ・イベントが取得されるか、または取得されないかを示す。本実施形態では、デバッグ例外は、ＥＬ１レベル、ＥＬ２レベルでのみ取得される。
レベル TDE KDE CPSR.D デバッグ・イベントに対するアクション
601 EL0 0 X X EL1で取得
602 1 X X EL2で取得
603 EL1 0 0 X 無視
604 0 1 1 無視
605 0 1 0 EL1へのリエントラント例外
606 1 X X EL2で取得
607 EL2 0 X X 無視
608 1 0 X 無視
609 1 1 1 無視
610 1 1 0 EL2へのリエントラント例外

【0081】

最初から２行の６０１と６０２は、ＥＬ０で実行時に何が起こるかを示している。ＴＤＥビットがクリアである場合（行６０１）、ＥＬ０でのデバッグ例外はＥＬ１で処理される。ＴＤＥビットが設定されている場合（行６０２）、ＥＬ０でのデバッグ例外はＥＬ２で処理される。ＣＰＳＲ．ＤフラグとＫＤＥビットは、ＥＬ０では何の影響も及ぼさないことに注意されたい。この表では、「Ｘ」は、「無関係」を意味し、これはその行のアクションはその列に対する値に依存しないということである。

【0082】

その次の４行、６０３、６０４、６０５、６０６は、ＥＬ１レベルで実行する場合の挙動を示している。ＴＤＥビットとＫＤＥビットの両方がクリアである場合（行６０３）、デバッグ例外は無視される。ＫＤＥビットが設定され、ＴＤＥビットがクリアである場合、デバッグ例外は、ＣＰＳＲ．Ｄフラグの値に応じてＥＬ１で許可されうる。行６０４では、ＣＰＳＲ．Ｄフラグも設定される。この場合、クリティカルなコードはＥＬ１レベルで実行されている。デバッグ・イベントは現在マスクされており、無視される。しかし、行６０５では、ＣＰＳＲ．Ｄフラグがクリアであり、ＥＬ１へのリエントラント例外としてデバッグ例外が許可される。行６０６では、ＫＤＥビットとＣＰＳＲ．Ｄフラグが無視され、デバッグ例外がＥＬ２で取得されるように、ＴＤＥビットが設定される。

【0083】

残りの４行、６０７、６０８、６０９、６１０は、ＥＬ２で実行する場合の挙動を示している。ＴＤＥビットまたはＫＤＥビットのいずれかがクリアである場合（行６０７、６０８）、デバッグ例外は無視される。しかし、ＴＤＥビットとＫＤＥビットの両方が設定されている場合、デバッグ例外はＣＰＳＲ．Ｄフラグの値に応じてＥＬ２で許可されうる。行６０９では、ＣＰＳＲ．Ｄフラグも設定されている。この場合、クリティカルなコードは、ＥＬ２レベルで実行されている。デバッグ・イベントは、現在マスクされており、無視される。しかし、行６１０では、ＣＰＳＲ．Ｄフラグがクリアであり、ＥＬ２へのリエントラント例外としてデバッグ例外が許可される。

【0084】

図６は、割り込みの受け取に応答して行われるステップを示している。ＥＬ０レベルで割り込みが受け取られると、割り込み例外がＥＬ１レベルで取得され、デバッグ・マスク・フラグが設定され、プロセッサの現在の状態を保存することに関連する割り込み例外を処理するために必要なクリティカルなコードが実行される。クリティカルなコードの実行中に、デバッグ・イベントが発生した場合、ＴＤＥビットまたはＫＤＥビットが設定されていない限り、無視するようにデバッグ・マスク・フラグが設定される。この実施形態では、ＴＤＥビットが設定されておらず、ＫＤＥビットが設定されている場合、ペンディングのデバッグ例外フラグが設定される。ＴＤＥビットが設定されていれば、例外はＥＬ２レベルにトラップされ、処理され、戻ると、クリティカルなコードの実行が終了し、ペンディングのデバッグ例外フラグは設定されない。他の実施形態では、ペンディングのデバッグ例外フラグは、デバッグ例外の特定タイプについて設定されうるが、他は設定されない（無視される）、または全く設定されない。

【0085】

クリティカルなコードの実行が終了すると、デバッグ・マスク・フラグが再設定され、デバッグ例外のペンディングのフラグを設定されているか否かを判断する。設定されている場合、ペンディングのデバッグ例外は取得され、設定されていない場合、割り込み例外の実行が継続する。

【0086】

図７は、図６と同様の流れ図であるが、クリティカルなコードの実行中に複数のデバッグ・イベントが発生したらどうなるかをさらに示しているため、より複雑である。従って、ＥＬ１に対する割り込みが受け取られ、取得されると、クリティカルなコードが実行され、デバッグ・マスクが設定される。次に、デバッグ・イベントが発生するか、デバッグ・イベントがペンディングしていることを示すペンディングのフラグを設定するかを判断する。いずれかが真であり、ＴＤＥビットが設定されていると、例外はＥＬ２で取得される。そうでなければ、ＥＬ１レベルでデバッグを許可しないようにＫＤＥビットが設定されていない場合、イベントは無視される。

【0087】

デバッグを許可することを示すＫＤＥビットが設定されていれば、デバッグ・マスクがまだ設定されているか（クリティカルなコードがまだ実行中であるか）を判断し、そうであれば、ペンディングのフラグが設定され、そうでなければ、リエントラント例外がＥＬ１で取得される。ペンディングのフラグは、累積し、これは既に設定されていれば、設定され続けることを意味する。

【0088】

例外が取得されないか、またはデバッグ・イベントが発生しなければ、デバッグ・マスクがまだ設定されているかを判断する。設定されていなければ、プロセッサがクリティカルなコードの処理を開始した時点であるかを判断し、そうであれば、デバッグ・マスク・フラグが設定され、そうでなければデバッグ・マスク・フラグは設定されない。デバッグ・マスクがまだ設定されていれば、プロセッサがクリティカルなコードの実行終了時点であるかを判断し、そうであればデバッグ・マスク・フラグはクリアされ、そうでなければ、クリアされない。次に、割り込みハンドラの終了に達したかを判断する。そうであれば、例外からＥＬ０への戻りが実行される。そうでなければ、デバッグ・イベントが発生し、そのメソッドのステップが繰り返されるかを判断する。

【0089】

図８は、使用可能な仮想マシンの実装を示している。前述の実施例では、本発明に関連する技術をサポートする特定の処理ハードウェアを稼働するための装置と方法で本発明を実装したが、いわゆるハードウェア・デバイスの仮想マシンの実装も可能である。こうした仮想マシンの実装は、仮想マシン・プログラム５１０をサポートするホストのオペレーティング・システム５２０を実行するホストのプロセッサ５３０で実行する。通常、妥当な速度で実行する仮想マシンの実装には通常大きな強力なプロセッサが必要である。しかし、こうしたアプローチは、互換性または再利用の目的で他のプロセッサに対してネイティブなコードの実行を望むような特定の状況で正当化される場合がある。仮想マシン・プログラム５１０は、アプリケーション・プログラム５００に対するアプリケーション・プログラム・インタフェースを提供する。アプリケーション・プログラム５００は、仮想マシン・プログラム５１０によってモデル化されているデバイスである実際のハードウェアによって提供されるアプリケーション・プログラム・インタフェースと同じである。従って、上記のメモリへのアクセスの制御を含むプログラム命令は、仮想マシン・プログラム５１０を使用して、仮想マシン・ハードウェアとのインタラクションをモデル化することにより、このアプリケーション５００内から実行されうる。

【0090】

本発明の例示的実施例は、添付図面を参照して詳細に説明したが、本発明はこうした実施形態そのものに限定されるものではないこと、および添付の請求項によって定義される本発明の範囲と精神から逸脱することなく当業者によって様々な変更や改良を行うことができることを理解されたい。例えば、本発明の範囲から逸脱することなく、以下の従属請求項の機能と、独立請求項の機能を様々に組み合わせることができる。

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6】

【図7】

【図8】