JP2006099755A - マルチタスクシステムをデバッグするためのデバッグシステム - Google Patents

Abstract

【課題】 マルチタスクシステムのデバッグを容易とするデバッグシステムとデバッグ方法、および、そのようなデバッグ方法を採用できる回路等を提供する。
【解決手段】 デバッグシステムは、デバッガプログラムを実行するホストコンピュータと、デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムが構築された回路とを含む。回路は、プログラムが読み込まれたメモリ、および、メモリ上のプログラムを実行可能な処理部を備えている。メモリは、第１マルチタスクシステムの１以上のタスクプログラムを管理する第１オペレーティングシステムと、第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納する。
【選択図】図４

Description

本発明は、マルチタスクシステムをデバッグするためのデバッグシステムおよびその方法に関する。より具体的には、本発明は複数のタスク処理と割込み処理で構成されるマルチタスクシステムのプログラムをデバッグするためのデバッグ方法、および、そのデバッグ方法を用いてデバッグを行うことが可能なシステム、回路等に関する。

従来のコンピュータシステムでは、１つのジョブを１つのタスクとして管理するシングルタスクプログラムを１つのプロセッサで処理していた。しかし近年は、一連の独立した複数のタスクで構成されるマルチタスクプログラムを１つのプロセッサ上で処理するマルチタスクシステムも多く開発されている。マルチタスクプログラムによれば、コンピュータ上で複数のタスクを見かけ上同時に（並列的に）実行させることが可能であり作業効率を向上させることができる。

コンピュータシステムの例として、光ディスクを利用して情報の記録および／または再生を行う光ディスクシステムが知られている。図２０は、従来の光ディスクシステムの概略的な構成を示す。光ディスクシステムは、光ディスク８が装填可能なドライブ装置９１およびホストコンピュータ９２から構成され、ホストインタフェースバス９３を介して接続されている。

この光ディスクシステムは、システムコントローラ９４および光ディスクコントローラ９５を含んでいる。システムコントローラ９４および光ディスクコントローラ９５は独立したＬＳＩとして実装されており、各々が別個のマルチタスクシステムとして機能している。

システムコントローラ９４は、内蔵されたホスト制御タスク１７１１とドライブ制御タスク１７２２に従って、ドライブ装置９１の全体の動作を制御する。例えば、システムコントローラ９４のＣＰＵ９６は、第１ＯＳによって管理されるホスト制御タスク１７１１、ドライブ制御タスク１７１２を処理している。

一方、光ディスクコントローラ９５は、各タスクに従って、光ディスク８への情報の記録と再生のためのアクセスを制御している。例えば、光ディスクコントローラ９５のＣＰＵ９７は、第２ＯＳによって管理されるサーボ制御タスク１７２１、ディスク制御タスク１７２２を処理している。

システムコントローラ９４および光ディスクコントローラ９５の各タスクは、連携しながらドライブ装置９１を動作させる。

例えば、システムコントローラ９４のドライブ制御タスク１７１２は、光ディスクコントローラ９５のディスク制御タスク１７２２に対してデータのリード要求またはライト要求を出す。すると、ディスク制御タスク１７２２はデータの読み出しまたは書き込みを実行する。読み出されたデータまたは書き込み完了／失敗の通知は、ドライブ制御タスク１７１２に返される。

マルチタスクプログラムの開発とともに、マルチタスクプログラムをデバッグする技術が種々開発されている。例えば特許文献１は、オペレーティング・システム（以下、「ＯＳ」と記す）上で動作するタスクの中から複数のタスクを指定し、指定されたタスクの何れかの実行が停止され、またはブレークポイントによって停止された場合に、デバッグ対象である他の指定されたタスクも同時に停止するタスクデバッグ方法を開示している。

また特許文献２は、デバッグのために、マルチタスクジョブを構成する任意のタスクが予め設定されたブレークポイントに到達し、または例外が発生した時点で、そのタスクと同一マルチタスクジョブグループ内のすべてのタスクの実行を停止させるマルチタスク制御方法を開示する。このマルチタスク制御方法によれば、任意の時点でそのマルチタスクジョブグループ内のすべてのタスクの実行を再開させることができる。
特開平２−３００９４２号公報 特開平４−３１４１４１号公報

図２０に示すような独立したマルチタスクシステムが複数含まれるコンピュータシステムにおいて、従来のデバッグ方法を用いて特定のマルチタスクシステムをデバッグすると、以下の２つの問題を生じる。

すなわち、第１の問題はシステムコントローラ９４および光ディスクコントローラ９５の各々に対して、個々のハードウェアに依存した第１ＯＳおよび第２ＯＳを開発し、さらに各ＯＳ上で実行されるタスクプログラムを作成する必要が生じる。これでは各コントローラのＬＳＩの部品コストだけでなく、ＯＳおよびタスクの開発コストが莫大にかかる。

また第２の問題は、従来のマルチタスクシステム用デバッグ方法では、割込み処理プログラムなどのデバッグができないことである。これは、従来のデバッグ方法が、デバッグ機能をタスクレベルで実現していることに起因する。すなわち、割込み処理を行うプログラムはタスクとして管理されておらず、独立したプログラムとして存在する。したがって割込み処理プログラムのデバッグをタスクのデバッグと同様に行うことができないため、割込み処理を含めたマルチタスクシステム全体のデバッグはできない。他のコントローラからの割込み要求を受け入れるためには、割込み処理プログラムのデバッグ環境も整える必要がある。

本発明の目的は、マルチタスクシステムのデバッグを容易とするデバッグシステムとデバッグ方法、および、そのようなデバッグ方法を採用できる回路等を提供することにある。

本発明によるデバッグシステムは、デバッガプログラムを実行するホストコンピュータと、前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムが構築された回路とを含む。前記回路は、プログラムが格納されたメモリ、および、前記メモリ上のプログラムを実行可能な処理部を備えている。前記メモリは、前記第１マルチタスクシステムの１以上のタスクプログラムを管理する第１オペレーティングシステムと、前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納する。

前記メモリには、前記第１マルチタスクシステムの実行を制御するためのモニタプログラムがさらに格納されていてもよい。前記処理部は、前記デバッガプログラムを実行した前記ホストコンピュータからのコマンドに応答して前記モニタプログラムを実行し、前記コマンドに応じた処理を実行して、前記ホストコンピュータに応答を返してもよい。

前記メモリは、前記第２オペレーティングシステムおよび前記１以上の第２タスクプログラムを、前記第２マルチタスクシステムとして格納してもよい。

前記メモリは、前記１以上の第２タスクプログラムとして、第３オペレーティングシステムおよび前記第３オペレーティングシステムによって管理される第３タスクプログラムを格納し、前記第３オペレーティングシステムおよび前記第３タスクプログラムを、前記第２マルチタスクシステムとして格納してもよい。

前記回路はスタックをさらに備え、前記処理部は、前記第１マルチタスクシステムの実行環境を前記スタックに退避し、その後、前記モニタプログラムに基づいて、前記第１マルチタスクシステムに含まれる１以上のタスクプログラムの実行を停止してもよい。

前記処理部は、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止する際に、前記第１オペレーティングシステムを停止状態に遷移させてもよい。

前記処理部は、処理が予め設定されたブレークポイントに到達すると、前記第１オペレーティングシステムを停止状態に遷移させて、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止してもよい。

前記処理部は、処理に例外が発生すると、前記第１オペレーティングシステムを停止状態に遷移させて、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止してもよい。

前記処理部は、前記第１オペレーティングシステム上で、前記第１マルチタスクシステムの割込み処理を実行可能であり、前記割込み処理を前記第１マルチタスクシステムのいずれのタスクプログラムよりも優先して実行してもよい。

前記処理部は、前記第１オペレーティングシステム上で、前記第１マルチタスクシステムの割込み処理を実行可能であり、前記処理部は、前記割込み処理を前記複合システムのいずれのタスクプログラムより優先して実行してもよい。

前記処理部によって実行される前記第１オペレーティングシステムは、前記割込み処理を割込みタスクプログラムとして管理しており、前記処理部は、前記割込みタスクプログラムを前記第１マルチタスクシステムのいずれのタスクプログラムより優先して実行してもよい。

前記処理部によって実行される前記第１オペレーティングシステムは、前記割込み処理を割込みタスクプログラムとして管理しており、前記処理部は、前記割込みタスクプログラムを前記複合システムのいずれのタスクプログラムより優先して実行してもよい。

本発明による回路は、デバッガプログラムを実行するホストコンピュータと接続され、前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムが構築されている。前記回路は、プログラムが格納されたメモリと、前記メモリ上のプログラムを実行可能な処理部とを備えている。前記メモリは、前記第１マルチタスクシステムの１以上のタスクプログラムを管理する第１オペレーティングシステムと、前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納してもよい。

本発明による回路は、デバッガプログラムを実行するホストコンピュータと接続され、前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムを構築することが可能である。前記回路は、プログラムが格納されたメモリと、前記メモリ上のプログラムを実行可能な処理部とを備えている。前記メモリは、第１オペレーティングシステムと、前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納しており、前記第１オペレーティングシステムは、前記メモリに１以上のタスクプログラムが読み込まれたとき、前記１以上のタスクプログラムを前記第１マルチタスクシステムのタスクプログラムとして管理してもよい。

本発明のデバッグシステムによれば、デバッグ対象の第１マルチタスクシステムを第１ＯＳによって管理し、さらに、その第１ＯＳをタスクとして第２ＯＳで管理し、さらに第２マルチタスクシステムを第２ＯＳによって管理する。第２ＯＳは１つのタスクとして第１ＯＳを管理しているため、第１マルチタスクシステムのタスクの影響を受けることなく、タスクの優先度を決定できる。

例えば、第１マルチタスクシステムのタスクにバグ等が存在し、そのバグに起因して第２ＯＳの各タスクの優先度を変更することはない。優先度の変更の影響は第１ＯＳで管理される他のタスクにのみ及び、第２ＯＳの各タスクが変更されることはないからである。

さらに第２ＯＳは、第１マルチタスクシステムのタスクを管理する必要がないため、第２ＯＳの実行に必要な処理負荷を抑えることができる。

以下、添付の図面を参照しながら、本発明の実施形態を説明する。

（実施形態１）
以下の説明では、まず本実施形態によるデバッグ方法によってプログラムがデバッグされたあとの集積回路（例えばＬＳＩ、ＶＬＳＩ）の構成およびその特徴を説明する。その後、プログラムのデバッグを実現するための構成およびデバッグ方法を説明する。

図１は、本実施形態によるデバッグ機能によって開発された第１の光ディスクシステムの構成を示す。光ディスクシステムは、光ディスク８が装填可能なドライブ装置１およびホストコンピュータ２から構成され、ホストインタフェースバス３を介して接続されている。ドライブ装置１がＤＶＤ−ＲＯＭドライブ等のコンピュータ周辺装置として使用される場合には、ドライブ装置１はＳＣＳＩ（Small Computer System Interface）等のホストインタフェースバス３を介して、ホストコンピュータ２との間でデータを授受する。

ドライブ装置１は、ディスクモーター５と、光ピックアップ６と、サーボ回路７と、光ディスクコントローラ１０７とを備えている。なお、図１には光ディスク８も記載されているが、これは説明の便宜のためである。光ディスク８はドライブ装置１から着脱可能であるため、ドライブ装置１の構成要素ではない。

光ディスクコントローラ１０７は、ドライブ装置１の動作を制御するＬＳＩである。光ディスクコントローラ１０７は、少なくともＣＰＵ９および実メモリ１０を含む。光ディスクコントローラ１０７による制御は、主として実メモリ１０に読み込まれたプログラムをＣＰＵ９が実行し、その実行結果としての命令がドライブ装置１の各構成要素に出力されることによって実現される。

ディスクモーター５は、光ディスク８を所定の回転速度で回転させる。光ピックアップ６は、レーザ光を放射してその反射光を検出し、反射光の光量に対応する光量信号を出力する。サーボ回路７は、光ピックアップ６からの光量信号に基づいてフォーカシング制御やトラッキング制御を実行する。

本実施形態によるデバッグ機能が採用されたことを示す主要な特徴は、ドライブ装置１には１つのＬＳＩ（光ディスクコントローラ１０７）のみが実装され、システムコントローラの機能と光ディスクコントローラの機能が同一ＣＰＵで実行されていることである。これは、従来のドライブ装置９４（図２０）におけるシステムコントローラの機能が光ディスクコントローラに組み込まれたことを意味する。ＬＳＩを１つにすることにより、複数のＬＳＩを実装する場合よりも部品コストが低減される。

光ディスクコントローラ１０７のＣＰＵ９は、実メモリ１０上に構築された１つのＯＳを介して複数のプログラム（複数のタスク）を実行する。複数のタスクとは、具体的にはホスト制御タスク１７１１、ドライブ制御タスク１７１２、サーボ制御タスク１７２１、ディスク制御タスク１７２２等である。

各タスクの具体的な処理は以下のとおりである。ホスト制御タスク１７１１は、ホストコンピュータ２とのインタフェース、および、スイッチ（図示せず）の押下等に関連するユーザとのインタフェースの動作を制御する。ドライブ制御タスク１７１２は、ドライブ装置１の起動・停止処理と、データのバッファリング処理等を制御する。サーボ制御タスク１７２１は、サーボ回路７の動作を制御する。ディスク制御タスク１７２２は、データの再生等を制御する。

図１に示す光ディスクシステムを実現するためには、１つのＣＰＵ９において実行可能なＯＳを開発し、すべてのタスクをそのＯＳが管理する必要がある。ＬＳＩベンダーは、正常に動作するＯＳ、サーボ制御タスク１７２１およびディスク制御タスク１７２２を予め組み込んだ状態で、ＬＳＩをドライブメーカーに販売する。そのドライブメーカーは、すでに組み込まれたＯＳ上で実行可能なホスト制御タスク１７１１、ドライブ制御タスク１７１２等を作成し、デバッグすることにより、光ディスクコントローラ１０７を完成させればよい。ＯＳを改めて開発する必要はないので、少なくともＯＳ開発のためのコストを削減できる。

ただし、このような光ディスクコントローラ１０７を開発するためには、これまで別のＯＳ上で動作可能であったタスクを１つのＯＳに適合するように修正しなければならない。

また、あるマルチタスクシステムのタスクに対して、別のマルチタスクシステムのタスクなどによってシステムコールが発行されると、マルチタスシステムのタスクの状態が変化してしまい、マルチタスシステムの動作が不正となる問題がある。このシステムコールは、例えばタスクのスケジューリングに関するシステムコール（レディキューの回転、タスクの優先度の変更）である。

例えば、図１のドライブ装置１において、光ディスクコントローラ１０７の開発中のドライブ制御タスク１７１２がバグを含んでいるとする。ドライブ制御タスク１７１２の誤った処理結果によって、ディスク制御タスク１７２２の優先度がサーボ制御タスク１７２１の優先度よりも下げられてしまうと、データの再生ができない等の不具合を生じることがある。

そこで、以下の説明においては、図１の構成をさらに改良した構成、および、そのような構成を実現するためのデバッグ機能、デバッグ方法を詳細に説明する。

図２は、本実施形態によるデバッグ機能によって開発された第２の光ディスクシステムの構成を示す。図１と同一構成部分には同一符号を付し、その説明は省略する。

第２の光ディスクシステムのドライブ装置１１もまた、第１の光ディスクシステムのドライブ装置１と同様、１つのＬＳＩ（光ディスクコントローラ１０７）のみが実装されている。システムコントローラの機能は光ディスクコントローラに組み込まれている。

図２に示す光ディスクシステムと図１に示す光ディスクシステムとの相違点は、光ディスクコントローラの実メモリ１１３上に構築されたプログラムの管理構造にある。

具体的には、図２の光ディスクコントローラ１０８に示すように、ホスト制御タスク１７１１およびドライブ制御タスク１７１２は第１ＯＳで管理される。これらは全体で１つのマルチタスクシステムを構成する。また、サーボ制御タスク１７２１、ディスク制御タスク１７２２および第１ＯＳは、第２ＯＳで管理される。これらもまた、別のマルチタスクシステムを構成する。なお、第１ＯＳはタスクの１つとして第２ＯＳによって管理される。その意味を明確にするために、以下では第１ＯＳを「第１ＯＳタスク」と記述する。

光ディスクコントローラ１０８のＣＰＵ１１１は、すべてのタスクを第２ＯＳ上で直接的にまたは間接的に管理できる。このように複数のマルチタスクシステムが構築された包括的なシステムを、複合型マルチタスクシステムと呼ぶ。

次に、本実施形態による複合型マルチタスクシステムの構成、および、複合型マルチタスクシステムのデバッグ方法を説明する。

図３は、複合型マルチタスクシステムが構築された大規模半導体集積回路（ＬＳＩ）１０９の構成を示す。ＬＳＩ１０９の一例が、図２に示す光ディスクコントローラ１０８である。

ＬＳＩ１０９は、ＣＰＵ１１１と、割り込み制御装置１１２と、実メモリ１１３とを有する。実メモリ１１３には、第２ＯＳ１３０、マルチタスクシステム１４０、１５０、および第１ＯＳタスク１６０が読み込まれ、配置されている。これらはＣＰＵ１１１により実行されるソフトウェア（コンピュータプログラム）である。このシステムは、独立した複数のマルチタスクシステム１４０および１５０を含んでおり、これらは１つのＣＰＵ１１１上で処理される。

マルチタスクシステム１４０はタスク１４１およびタスク１４２から構成され、第２ＯＳ１３０によって管理されている。デバッグ対象マルチタスクシステム１５０は、タスク１５１およびタスク１５２から構成され、第１ＯＳタスク１６０によって管理される。

図３に示される複合型マルチタスクシステムを構築すると、ＬＳＩ１０９の開発を容易化できるという利点がある。具体的には以下のとおりである。

まず第１に、第１ＯＳタスク１６０を第２ＯＳ１３０で管理することにより、独立した２つのマルチタスクシステム１４０および１５０は異なるＯＳで管理される。その結果、すべてのタスクを１つのＯＳ上で動作するように設計する必要はなくなる。従来のＯＳで動作していたタスクをそのまま利用することも可能となる。このときは、第１ＯＳタスク１６０のみを第２ＯＳ１３０に適合させ、かつ、従来のＯＳの仕様を実装するように開発しなおせば足りる。よって、開発に必要なコストを低減できる。

第２に、第２ＯＳ１３０によって管理されるタスクは、タスク１４１、タスク１４２および第１ＯＳタスク１６０の３つである。図示されているタスク１４１、１４２、１５１および１５２を第２ＯＳ１３０によって管理する場合と比較すると、第２ＯＳ１３０が管理すべきタスクの数は少なくなる。その結果、タスク間の優先度を決定する際に、考慮すべきタスクが少なくなり、開発が容易になる。この利点は、第１ＯＳタスク１６０によって管理されるタスクの数が増えるほど顕著になる。

さらに第３には、複合型マルチタスクシステムにおいては、一方のマルチタスクシステムのタスクが他方のマルチタスクシステムのタスクに与える影響を遮断できるという利点がある。例えば、マルチタスクシステム１５０のタスク１５１がレディキューの回転のシステムコールを発行したとする。しかし、このときの影響は第１ＯＳ１６０で管理される他のタスク１５２にのみ及び、他のマルチタスクシステム１４０のタスク１４１、１４２および第１ＯＳタスク１６０には及ばない。

以下、本実施形態によるデバッグシステムの構成およびデバッグ方法を説明する。以下のデバッグシステムを利用してプログラムをデバッグすることにより、図３に示すＬＳＩ１０９を得ることができる。例えば光ディスク用途のＬＳＩのプログラムをデバッグすると、図２に示す光ディスクコントローラ１０８を得ることができる。

図４は、本実施形態によるデバッグシステムの全体構成を概略的に示す。このデバッグシステムは、インタフェースバス１９０を介して接続されたターゲットシステム１１０とホストコンピュータ１７０とを有している。

ターゲットシステム１１０は、中央処理ユニット（ＣＰＵ）１１１と割込み制御装置１１２と実メモリ１１３から構成される。

実メモリ１１３には、モニタプログラム１２０、第２ＯＳ１３０、マルチタスクシステム１４０、デバッグ対象マルチタスクシステム１５０および第１ＯＳタスク１６０が読み込まれ、配置されている。これらはＣＰＵ１１１により実行されるソフトウェア（コンピュータプログラム）である。このシステムは、独立した複数のマルチタスクシステム１４０および１５０を含んでおり、これらは１つのＣＰＵ１１１上で処理される。よって、このシステムは複合型マルチタスクシステムといえる。

マルチタスクシステム１４０はタスク１４１およびタスク１４２から構成され、第２ＯＳ１３０によって管理されている。デバッグ対象マルチタスクシステム１５０は、タスク１５１およびタスク１５２から構成され、第１ＯＳタスク１６０によって管理される。第１ＯＳタスク１６０は、第２ＯＳ１３０によって管理されるタスクのひとつである。ＣＰＵ１１１および割込み制御装置１１２の構成および動作は図５を参照しながら後述する。

また、ホストコンピュータ１７０には、デバッガ１８０が配置される。デバッガ１８０とは、プログラムの誤り(バグ)を発見してその修正を支援するソフトウェアであり、ホストコンピュータ１７０の図示しない実メモリに読み込まれ、そのＣＰＵによって実行される。

ターゲットシステム１１０はインタフェースバス１９０を介してホストコンピュータ１７０と接続される。

モニタプログラム１２０はデバッガ１８０からの通信による割込みにより起動される。起動されたモニタプログラム１２０は、デバッガ１８０からのデバッグコマンドを受信し、受信したコマンドに対応した処理を実行し、デバッガ１８０に応答を返す。これにより、デバッグ対象マルチタスクシステム１５０のデータの参照および変更、ブレークポイントの設定などを行うと共に、デバッグ対象マルチタスクシステム１５０の実行を制御する。例えば、モニタプログラム１２０がデバッガからデータの参照を要求するコマンドとともに、参照されるデータのアドレスを受信する。そして指定されたアドレスからデータを取得し、デバッガ１８０に取得したデータを返す。これにより、ユーザはデータを確認することができる。なお、上述の「ブレークポイント」とは、プログラムの実行を中断するプログラムの特定の行（プログラム上の位置）を意味する。

図５は、ＣＰＵ１１１および割込み制御装置１１２の構成を詳細に示す。図５に示す構成のうち、図４に示す構成と同一の部分には同一符号を付している。図５は、ｎ個の割込みグループの割込みを受け付け可能なシステムの例である。ＣＰＵ１１１と接続される周辺装置からの割込み（例えばキー入力を受けたキーボード（図示せず）からの割込み）は、割込み制御装置１１２を介してＣＰＵ１１１に送出される。割込みを受理したＣＰＵ１１１は、現在実行中のプログラムを中断して、割込み処理プログラムの実行を開始する。割込み制御装置１１２は、割込みグループ制御部２００（１）〜２００（ｎ）を備え、ＣＰＵ１１１に送出する割込みを制御している。また、各割込みグループ制御部（２００（１）〜２００（ｎ））は割込み制御レジスタ（図示せず）を備え、割込みグループごとに割込み優先レベル、割込みの許可／禁止の設定をすることができる。

次に、図６を参照しながら、予め設定されたブレークポイントあるいは例外を発した時点で、デバッグ対象マルチタスクシステム１５０のタスク１５１を停止する処理を説明する。図６は、デバッグ対象マルチタスクシステム１５０を停止するモニタプログラム１２０の処理手順の例を示すフローチャートである。上述のように、モニタプログラム１２０はＣＰＵ１１１において実行される。デバッグ対象マルチタスクシステム１５０のタスク１５１のプログラムがブレークポイントに到達する、あるいは例外が発生すると、制御がモニタプログラム１２０のマルチタスクシステム停止処理に切り替えられる。

まず、ステップＳ３０１において前処理が行われる。前処理とは、現在実行中のタスク１５１のレジスタ群、プログラムカウンタ、ステータスレジスタ等の値をメモリ１１３に構築されたスタック（図示せず）等に退避する処理である。この処理により、デバッグ対象マルチタスクシステム１５０のタスクの実行環境が保持される。なお、退避先はスタックに限られず、スタック以外のメモリ１１３またはその他のメモリ（図示せず）であってもよい。

ステップＳ３０２において、ＣＰＵ１１１は第２ＯＳ１３０に対し、第１ＯＳタスクを強制待ち（サスペンド）状態へ遷移させるシステムコールを発行する。その結果、第１ＯＳタスク１６０の実行を停止させる。このとき、第２ＯＳ１３０は、システムコールを受けて第１ＯＳタスクを強制待ち状態へ遷移させる処理を実行する。

次のステップＳ３０３では、ＣＰＵ１１１は、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止する。割込みの禁止は、例えば、割込み制御装置１１２の割込み制御レジスタのうちの、デバッグ対象マルチタスクシステム１５０の割込みを制御するレジスタを割込み禁止に設定にすることによって実現される。

そしてステップＳ３０４において、ＣＰＵ１１１は、第２ＯＳ１３０のタスクディスパッチ処理を実行する。タスクディスパッチ（以下、単に「ディスパッチ」と記述する）処理とは、第２ＯＳ１３０がタスクの優先度を基準にタスクの実行順序をスケジューリングし、最高優先度のタスクをＣＰＵ１１１が実行する対象として切り替える処理である。ここではディスパッチ処理により、第１ＯＳタスク１６０から、他の最優先のタスク（タスク１４１または１４２）にタスクの切り替えが行われる。これによりデバッグ対象マルチタスクシステム１５０の複数タスク（タスク１５１および１５２）の実行が抑制される。

その後、ステップＳ３０５において、切り替え後の最優先タスク（タスク１４１または１４２）のレジスタ復帰等の後処理が行われ、モニタプログラム１２０の処理が終了する。

次に、図７を参照しながら、停止したデバッグ対象マルチタスクシステム１５０の再開処理を説明する。この処理は、デバッグ対象マルチタスクシステム１５０のデバッグが終了した後に行われる。

図７はデバッグ対象マルチタスクシステム１５０の処理を再開するモニタプログラム１２０の処理例を示すフローチャートである。まず、任意の時点で、ユーザがデバッガ１８０経由でデバッグ対象マルチタスクシステム１５０の処理の再開を指示する。すると、制御はモニタプログラムのマルチタスクシステム再開処理に切り替えられる。

ステップＳ４０１において、ＣＰＵ１１１は現在実行中のタスクのレジスタ退避等の前処理を行う。これはステップＳ３０１と同様の処理である。ステップＳ４０２では、ＣＰＵ１１１は、第２ＯＳ１３０に対し、第１ＯＳタスク１６０の実行を再開させるためのシステムコールを発行する。システムコールに応答して、第２ＯＳ１３０は第１ＯＳタスク１６０を強制待ち状態から実行可能状態にする。

次にステップＳ４０３において、ＣＰＵ１１１は、デバッグ対象マルチタスクシステムの割込み禁止を解除する。これ以降、上述のステップＳ３０３において禁止されていた割込みが許可される。

ステップＳ４０４では、ＣＰＵ１１１は、第２ＯＳ１３０のディスパッチ処理を実行する。その後、第１ＯＳタスク１６０の実行再開が許可されると、タスクのレジスタ復帰等の処理が行われ、実行環境が復元される。

以上の処理の結果、デバッグ対象マルチタスクシステム１５０の複数タスク（タスク１５１および１５２）の実行を再開することができる。

本実施形態によれば、デバッグ対象マルチタスクシステム１５０を第１ＯＳタスク１６０で管理し、デバッグ対象マルチタスクシステム１５０の任意のタスク（タスク１５１またはタスク１５２）がブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止する。これにより、デバッグ対象マルチタスクシステム１５０を構成するすべてのタスク（１５１および１５２）について、その実行環境を保持した状態で実行を抑制することが可能となる。

また、デバッグ対象マルチタスクシステム１５０の停止中に他の実行中のタスクなどによる、タスクの状態を変化させるようなシステムコールが第２ＯＳ１３０に対して発行されても、第１ＯＳタスク１６０で管理されているデバッグ対象マルチタスクシステム１５０のタスク１５１および１５２には影響を与えず、マルチタスクシステムのデバッグを容易化できる。

一方、デバッグ対象マルチタスクシステム１５０のタスク１５１および１５２からタスクの状態を変化させるようなシステムコールが発行されても、このとき影響は第１ＯＳ１６０で管理されるタスクにのみ及び、他のマルチタスクシステム１４０のタスク１４１、１４２および第１ＯＳタスク１６０には及ばない。

ＯＳや基本的なタスクが組み込まれたＬＳＩの購入者は、タスク１５１および１５２として、例えばドライブ制御タスクおよびホスト制御タスクを開発し、デバッグして組み込むことにより、ドライブ装置１１（図２）の光ディスクコントローラ１０８を得ることができる。

なお、本実施形態では、ブレークポイントに到達した時点あるいは例外が発生した時点で第１ＯＳタスク１６０を強制待ち状態に遷移させるシステムコールで第１ＯＳタスク１６０の実行を停止している。しかし、第１ＯＳタスク１６０の実行を抑制することができるのであれば、例えば、待ち（ウエイト）状態に遷移させるシステムコールを用いて第１ＯＳタスク１６０の実行を停止させてもよい。

本実施形態では、ターゲットシステム１１０が２つのマルチタスクシステム１４０と１５０で構成される例で説明したが、上述の処理は３つ以上のマルチタスクシステムで構成されていても適用できる。また、各マルチタスクシステム１４０と１５０が各２つのタスクで構成される例を挙げて説明したが、各マルチタスクシステム１４０および１５０の一方、または、双方が３つ以上のタスクで構成される場合にも適用できる。

本実施形態では、第２ＯＳ１３０が第１ＯＳタスク１６０および非デバッグ対象のマルチタスクシステム１４０をタスクとして管理し、さらに第１ＯＳタスク１６０がデバッグ対象のマルチタスクシステム１５０を管理するとして説明した。しかし、デバッグ対象および非デバッグ対象の各マルチタスクシステムをそれぞれ管理するＯＳを設け、さらにそれらのＯＳをタスクとして有する包括的なＯＳを設けて管理を行ってもよい。例えば、図１４は、本実施形態の変形例によるシステムの管理構造を示す。このシステムでは、第１ＯＳタスク１６０によってデバッグ対象のマルチタスクシステム１５０を管理し、第３ＯＳ１１１０によってデバッグ対象のマルチタスクシステム１４０を管理している。そして、第２ＯＳ１３０が、第１ＯＳ１６０および第３ＯＳ１１１０をタスクとして有し、その処理を管理している。このような管理構造をとると、非デバッグ対象のマルチタスクシステムが２つ以上ある場合においても、各非デバッグ対象のマルチタスクシステムをＯＳタスクで管理し、各ＯＳタスクを第２ＯＳ１３０で管理できるため、画一的な処理が可能であり、汎用性の高いシステムを構築できる。また、第２ＯＳ１３０は各ＯＳタスクのみを管理するよう設計すればよいので、開発に要するコストを低減できる。

なお、本実施形態においては、図１に示す光ディスクコントローラ１０７のマルチタスクシステムを得るためのデバッグシステムを説明していない。しかし、そのようなデバッグシステムは、例えば図４に示すターゲットシステム１１０の構成から第１ＯＳタスク１６０を省くことによって得ることができる。なお、先に述べたように、１つのＯＳに適合するように各タスクを開発する必要等が生じることに留意されたい。

（実施形態２）
図８は本実施形態によるデバッグシステムの全体構成を概略的に示す。図８に示す構成のうち、図４に示す構成と同一の部分には同一符号を付している。図８の構成要素のうち、実施形態１において説明した要素の説明は省略する。

本実施形態によるデバッグシステムにおいては、実施形態１で説明したデバッグシステム（図４）の構成に加えて、実メモリ中１１３に仮想割込み制御プログラム５１０が配置されている。また、デバッグ対象マルチタスクシステム１５０は、タスク１５１、タスク１５２および割込み処理５００から構成される。

以下、仮想割込み処理を説明する。本実施形態による仮想割込み処理は、デバッグ対象マルチタスクシステムの割込み処理５００をタスクとして第１ＯＳタスク１６０で管理する。そして、仮想割込み制御プログラム５１０により、他のタスク（タスク１４１、１４２、１５１，１５２）より優先して割込み処理タスクを実行させる。以下では、このような割込み処理タスクを「割込み処理タスク」と記述する。

まず、図８の各タスクの優先度を以下に示すとおりとする。すなわち、第１ＯＳタスク１６０が管理する各タスクの優先度を、
割込み処理タスク５００＞割込み処理タスク以外のタスク（タスク１５１および１５２）
とする。また、割込み処理タスク５００の起動時には、第２ＯＳ１３０が管理する各タスクの優先度を、
第１ＯＳタスク１６０＞第１ＯＳタスク以外のタスク（タスク１４１および１４２）
とする。

また、デバッグ対象マルチタスクシステム１５０において、割込み処理が複数ある場合は、割込み処理タスクの優先度を異ならせて、レベル割込みの機能を仮想割込み処理で実行することが可能である。例えば、デバッグ対象マルチタスクシステム１５０の割込み１、割込み２があり（ただし、割込みレベルの優先度は、割込み１＞割込み２とする）、各割込みに対応する割込み処理タスクをそれぞれ、割込み処理タスク１、割込み処理タスク２とする。このときのタスクの優先度を
割込み処理タスク１＞割込み処理タスク２
とすることにより、レベル割込みに対応した仮想割込み処理を実現することが可能である。

次に、仮想割込み制御プログラム５１０の割込み処理タスク５００の起動および終了処理を説明する。

図９は割込みを判定する処理の例を示すフローチャートである。ステップＳ６０１において、まず、割込みが発生すると、制御は仮想割込み制御プログラム５１０の割込み判定処理に切り替えられる。ＣＰＵ１１１はレジスタ退避、スタックの切替などの前処理を行う。次に、ステップＳ６０２において、その割込みが、デバッグ対象マルチタスクシステム１５０の割込みに該当するか否かを判定する。該当するときは、処理はステップＳ６０５に進み、しないときはステップＳ６０３に進む。

ステップＳ６０３では、ＣＰＵ１１１は通常の割込み処理と同様に割込み処理プログラムを実行し、ステップＳ６０４においてレジスタの復帰、ディスパッチ処理などの後処理を実行し、割込みから復帰する。

一方、ステップＳ６０５では、ＣＰＵ１１１は、割込み処理タスク５００の起動処理を行う。この処理の詳細を、以下、図１０を参照しながら詳述する。

図１０は、割込み処理タスク５００を起動する処理の例を示すフローチャートである。まずステップＳ７０１において、ＣＰＵ１１１は、第２ＯＳ１３０に対して第１ＯＳタスク１６０の優先度変更のシステムコールを発行し、第１ＯＳタスク１６０の優先度を最高（最優先）に変更する。そしてステップＳ７０２において、ＣＰＵ１１１は第２ＯＳ１３０のディスパッチ処理を実行する。この結果、実行の対象が、最高優先度のタスクである第１ＯＳタスク１６０に切り替えられる。

次のステップＳ７０３では、ＣＰＵ１１１は、割込み処理タスク５００を起動するために、第１ＯＳタスク１６０に割込み処理タスク５００のタスク起動のシステムコールを発行する。そしてステップＳ７０４において、ＣＰＵ１１１は、第１ＯＳタスク１６０のディスパッチ処理を実行する。これにより、最高優先度である割込み処理タスク５００がディスパッチされる。

さらにＣＰＵ１１１は、ステップＳ７０５において、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止する。そして、割込みから復帰し、割込み処理タスク５００を実行する。

次に、図１１を参照しながら、割込み処理タスクの終了時の処理を説明する。図１１は、割込み処理タスク５００終了時の処理の例を示すフローチャートである。ステップＳ８０１において、ＣＰＵ１１１は、割込み処理タスク５００を第１ＯＳタスク１６０のレディキューから外し、休止状態に遷移させる。なお、「レディキュー」（Ｒｅａｄｙ Ｑｕｅｕｅ）とは、実行可能状態のタスクを管理するために使用する行列である。タスクはレディ状態になると、優先度毎に待ち行列に配置される。この待ち行列のことをレディキューと呼ぶ。

次のステップＳ８０２では、ＣＰＵ１１１は、他の割込み処理タスクが起動されているか否かをチェックする。起動されていないときはステップＳ８０３に進み、起動されているときはステップＳ８０４に進む。

ステップＳ８０３では、第１ＯＳタスク１６０の優先度を元に戻すために、ＣＰＵ１１１は、第２ＯＳ１３０に第１ＯＳタスク１６０の優先度変更のシステムコールを発行する。

ステップＳ８０４では、ＣＰＵ１１１は、第１ＯＳタスク１６０のディスパッチ処理を実行する。これにより、実行対象が最高の優先度をもつタスクに切り替えられる。

ディスパッチ処理により実行状態となったタスクに対応した割込み許可および禁止の状態にするために、ステップＳ８０５において、ＣＰＵ１１１は、デバッグ対象マルチタスクシステムの割込み許可／禁止設定処理を実行する。例えば、ステップＳ８０４の第１ＯＳタスク１６０へのディスパッチ処理後に、実行状態となったタスクが割込み禁止状態の割込み処理タスクなどである場合には、デバッグ対象マルチタスクシステム１５０の割込みを割込み禁止に設定する。また、割込み許可状態のタスクなどである場合には、禁止したデバッグ対象マルチタスクシステム１５０の割込みを割込み許可に設定する。

割込み許可／禁止設定処理は、以下の処理によって実現される。すなわち、第１ＯＳタスク１６０は、各タスク（タスク１５１、タスク１５２および割込み処理タスク５００）の割込み許可および禁止の状態を管理する情報（以下、「割込み管理情報」という）を保持する。例えば第１ＯＳタスク１６０は、タスク・コントロール・ブロック（ＴＣＢ）にタスクの割込み許可状態であるかの割込み許可フラグ、および、受付可能な割込みレベルを設定するための割込みマスクレベルを保持する。その後、第１ＯＳタスク１６０のディスパッチ処理によって実行状態となったタスクの割込み管理情報を参照し、デバッグ対象マルチタスクシステム１５０の割込みの割込み許可および禁止を設定すればよい。例えば、割込み制御装置１１２の割込み制御レジスタのうち、デバッグ対象マルチタスクシステム１５０の割込みを制御する割込み制御レジスタの設定を割込み許可および禁止に設定する。

次のステップＳ８０６において、ＣＰＵ１１１は、第２ＯＳ１３０のディスパッチ処理を実行する。これにより、この時点での最優先のタスクが実行される。

以上のように、割込み処理を１つのタスクとして第１ＯＳタスク１６０で管理し、仮想割込み制御プログラム５１０によって、他タスク（タスク１４１、１４２、１５１，１５２）より優先的に割込み処理タスク５００を実行する。優先度を設定できるため、通常の割込み処理同様に割込み処理タスク１５０を優先して実行することが可能となる。

次に、デバッグ対象マルチタスクシステム１５０のタスク（タスク１５１および１５２）および割込み処理タスク５００の停止処理を説明する。

デバッグ対象マルチタスクシステム１５０のタスク（タスク１５１またはタスク１５２）の停止処理は、実施形態１と同様に、マルチタスクシステムを構成する任意のタスクがブレークポイントに到達した時点、あるいは例外が発生した時点で行われる。この時点において、ＣＰＵ１１１は第１ＯＳタスク１６０の実行を停止する。デバッグ対象マルチタスクシステム１５０の割込み処理においても割込み処理タスク５００として第１ＯＳタスク１６０でタスクとして管理されるので、通常のタスク（タスク１５１またはタスク１５２）同様にブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止することにより、デバッグ対象マルチタスクシステム１５０が停止する。停止したデバッグ対象マルチタスクシステム１５０の再開処理は、実施形態１で説明した再開処理と同様である。

次に仮想割込み処理の動作例を説明する。この例は、タスク１４１が実行中であり、割込み処理タスクは起動していないときの仮想割込み処理の動作例である。また、第２ＯＳ１３０が管理しているタスクの優先度を
タスク１４１（優先度２）＞タスク１４２（優先度３）＞第１ＯＳタスク１６０（優先度４）
とする。割込み処理タスクの起動処理のために第１ＯＳタスク１６０の優先度を最優先にした時には、各タスクの優先度を
第１ＯＳタスク１６０（優先度１）＞タスク１４１（優先度２）＞タスク１４２（優先度３）
とする。また、第１ＯＳタスク１６０が管理するタスクの優先度を
割込み処理タスク５００（優先度１）＞タスク１５１（優先度２）＞タスク１５２（優先度３）
とする。

図１２（ａ）は、デバッグ対象マルチタスクシステムの割込みが発生したときのタスクの遷移のタイミングを示す。図１２（ｂ）は、非デバッグ対象のマルチタスクシステムの割込みが発生したときの、タスクの遷移のタイミングを示す。図１３は、割込み処理タスクの起動処理および終了処理における、第１ＯＳタスク１６０および第２ＯＳ１３０のレディキューの状態を示す。

まず、デバッグ対象マルチタスクシステム１５０の割込みが発生したときの動作を説明する。

図１２（ａ）の９０１および図１３（ａ）に示すように、デバッグ対象マルチタスクシステム１５０の割込みが発生すると、ＣＰＵ１１１は制御を仮想割込み制御プログラム５１０の割込み判定処理に切り替える。レジスタ退避、スタックの切替などの前処理（ステップＳ６０１）を行う。次に、デバッグ対象マルチタスクシステム１５０の割込みであるか否かを判定する（ステップＳ６０２）。ここではデバッグ対象マルチタスクシステム１５０の割込みであるから、割込み処理タスクの起動処理を実行する（ステップＳ６０５）。

次に図１３（ｂ）に示すように、第１ＯＳタスク１６０の優先度を最高優先度にするシステムコールを第２ＯＳ１３０に対して発行し（ステップＳ７０１）、第２ＯＳ１３０のディスパッチ処理を実行する（ステップＳ７０２）。これにより、タスク１４１から最高優先タスクである第１ＯＳタスク１６０への切り替えが行われる。次に図１３（ｃ）に示すように、第１ＯＳタスク１６０に割込み処理タスクの起動に関するシステムコールが発行され（ステップＳ７０３）、第１ＯＳタスク１６０のディスパッチ処理を実行する（ステップＳ７０４）。これにより、最高優先度である割込み処理タスク５００が実行対象に割り当てられる。次に、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止し（ステップＳ７０５）、割込みから復帰し、割込み処理タスク５００の実行が開始される（図１２（ａ）の９０２）。

割込み処理タスク５００が終了すると（図１２（ａ）の９０３）、図１３（ｄ）から理解されるように、割込み処理タスク５００を第１ＯＳタスク１６０のレディキューから外して休止状態に遷移させる（ステップＳ８０１）。次に、他の割込み処理タスクが起動されていないかがチェックされる（ステップＳ８０２）。

起動されていないので、第１ＯＳタスク１６０の優先度を元に戻すために、図１３（ｅ）に示すように、第２ＯＳ１３０に第１ＯＳタスク１６０の優先度変更のシステムコールを発行する（ステップＳ８０３）。そして、第１ＯＳタスク１６０のディスパッチ処理を実行することにより（ステップＳ８０４）、タスク１５１が実行状態となり、タスク１５１の割込み状態に応じてデバッグ対象マルチタスクシステムの割込み設定が行われる（図１１ステップＳ８０５）。さらに、第２ＯＳ１３０のディスパッチ処理を実行する（ステップＳ８０６）。これにより、この時点での最優先のタスク１４１が実行される（図１２（ａ）の９０４）。

次に、非デバッグ対象のマルチタスクシステムの割込みが発生した場合の動作を説明する。

割込みが発生すると(図１２（ｂ）の９０５)、ＣＰＵ１１１は制御を仮想割込み制御プログラム５１０の割込み判定処理に切り替える。そしてレジスタの退避、スタックの切替などの前処理（ステップＳ６０１）を行う。その後、その割込みがデバッグ対象マルチタスクシステム１５０の割込みであるかが判定される（ステップＳ６０２）。ここではデバッグ対象マルチタスクシステム１５０の割込みでないので、割込み処理プログラムへ分岐する（図９のステップＳ６０３、図１２（ｂ）の９０６）。割込み処理プログラムの実行後、仮想割込み処理に戻る(図１２（ｂ）の９０７)。レジスタの復帰、ディスパッチ処理などの後処理を実行し（ステップＳ６０４）、割込みから復帰する（図１２（ｂ）の９０８）。

本実施形態によれば、実施形態１において説明した効果とともに、さらに以下の効果が得られる。すなわち、割込み処理同等の動作をさせる仮想割込み処理によって、デバッグ対象マルチタスクシステムの割込み処理を第１ＯＳタスク１６０で管理し、ブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止する。これにより、デバッグ対象マルチタスクシステム１５０を構成するすべてのタスク（タスク１５１およびタスク１５２）および割込み処理５００に関し、その実行環境を保持した状態で実行を抑制できる。これにより、割込み処理を含むマルチタスクシステム全体のデバッグが可能となり、デバッグを容易化できる。

なお、本実施形態では、ターゲットシステム１１０が２つのマルチタスクシステム１４０と１５０で構成される例で説明したが、３つ以上のマルチタスクシステムで構成される場合にも本発明は適用可能である。また、各マルチタスクシステム１４０と１５０においてもタスク数をそれぞれ２つで構成される例で説明したが、各マルチタスクシステム１４０と１５０の一方、または、双方が３つ以上のタスクで構成される場合にも本発明は適用可能である。また、デバッグ対象マルチタスクシステム１５０の割込み処理数が１つで構成される例で説明したが、２つ以上の割込み処理で構成される場合にも本発明は適用可能である。

なお、本実施形態では、非デバッグ対象のマルチタスクシステム１４０は第２ＯＳ１３０で管理されるが、第２ＯＳ１３０で管理されるＯＳタスクで管理してもよい。また、非デバッグ対象のマルチタスクシステムが２つ以上ある場合においても、各非デバッグ対象のマルチタスクシステムをＯＳタスクで管理し、各ＯＳタスクを第２ＯＳ１３０で管理してもよい。

なお、本実施形態では、割込み処理タスクの起動処理の割込み禁止処理（図１０のステップＳ７０５）、および、割込み処理タスク終了処理の割込み許可／禁止処理（図１１のステップＳ８０５）において、デバッグ対象マルチタスクシステム１５０のすべての割込みを許可および禁止する例で説明したが、デバッグ対象マルチタスクシステム１５０およびマルチタスクシステム１４０のすべての割込みを許可および禁止してもよい。

（実施形態３）
本実施形態のデバッグシステムの全体構成は、図８を参照して説明したデバッグシステムの構成と同一である。よって、特に改めて説明しない構成要素および動作については、先の実施形態で説明したとおりとする。

以下、本実施形態による仮想割込み処理を説明する。本実施形態の仮想割込み処理は、デバッグ対象マルチタスクシステムの割込み処理５００をタスク（割込み処理タスク）として第１ＯＳタスク１６０で管理し、仮想割込み制御プログラム５１０により、デバッグ対象マルチタスクシステムのタスク（タスク１５１，１５２）より優先に割込み処理タスクを実行させる処理として実現する。以下、その処理を説明する。

まず、図８の各タスクの優先度を以下に示すとおりとする。すなわち、第１ＯＳタスク１６０が管理する各タスクの優先度を、
割込み処理タスク５００＞割込み処理タスク以外のタスク（タスク１５１および１５２）
とする。また、第２ＯＳ１３０が管理する各タスクの優先度に関しては、優先度の制約はない。

また、デバッグ対象マルチタスクシステム１５０に、割込み処理が複数存在する場合は、実施形態２と同様に、割込み処理タスクの優先度を異ならせることにより、レベル割込みの機能を仮想割込み処理で実行することが可能である。

次に、本実施形態の仮想割込み制御プログラム５１０の割込み処理タスク５００の起動および終了処理を説明する。なお、割込みを判定する処理は図９に示す手順で行われる。

まず、割込みが発生すると、ＣＰＵ１１１は制御を仮想割込み制御プログラム５１０の割込み判定処理に切り替える。そしてレジスタ退避、スタックの切替などの前処理（図９のステップＳ６０１）を行う。次に、デバッグ対象マルチタスクシステム１５０の割込みであるか否かを判定する（図９のステップＳ６０２）。

デバッグ対象マルチタスクシステム１５０の割込みでない場合は、通常の割込み処理と同様に、割込み処理プログラムを実行し（図９のステップＳ６０３）、レジスタの復帰、ディスパッチ処理などの後処理を実行し（図９のステップＳ６０４）、割込みから復帰する。

デバッグ対象マルチタスクシステムの割込みの場合は、割込み処理タスクの起動処理を実行する（図９のステップＳ６０５）。この処理は図１５に示されている。

図１５は、本実施形態の割込み処理タスク５００を起動する処理の例を示すフローチャートである。

まずステップＳ１２０１において、ＣＰＵ１１１は割込み処理タスク５００を起動するために第１ＯＳタスク１６０にタスク起動のシステムコールを発行し、ステップＳ１２０２において、第１ＯＳタスクが実行中であるか確認する。実行中のときはステップＳ１２０３に進み、実行中でないときはステップＳ１２０５に進む。

ステップＳ１２０３では、ＣＰＵ１１１は第１ＯＳタスク１６０のディスパッチ処理を実行する。これにより、最高優先度である割込み処理タスク５００がディスパッチされる。さらにステップＳ１２０４では、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止し、その後、割込みから復帰し、割込み処理タスク５００を実行する。

一方、ステップＳ１２０５では、ＣＰＵ１１１は第１ＯＳタスク１６０がディスパッチされた後に、割込み処理タスク５００をディスパッチするために、割込み処理タスクの起動要求を設定する。この起動要求の設定は、例えば、割込み処理タスクの起動要求フラグをセットすることにより行う。次に、ステップＳ１２０６において、レジスタの復帰などの後処理を実行し、割込みから復帰する。

続いて、第２ＯＳにおいて、第１ＯＳタスク１６０がディスパッチされた後に、第１ＯＳタスクにおいて割込み処理タスク５００をディスパッチする処理を説明する。図１６は、第２ＯＳのディスパッチ処理の例を示すフローチャートである。

まず、ステップＳ１３０１において、ＣＰＵ１１１は第２ＯＳのタスクスケジューリングを実行し、実行状態のタスクが第１ＯＳタスクであり、かつ、割込み処理タスクの起動要求があるかどうかを判定する。条件を満たすときはステップＳ１３０３に進み、満たしていないときはプログラムにリターンし、第２ＯＳのタスクスケジューリングで実行状態となったタスクを実行する。

ステップＳ１３０３において、ＣＰＵ１１１は、第１ＯＳタスクのディスパッチ処理を実行する。これにより、割込み処理タスク５００がディスパッチされる。さらにステップＳ１３０４において、ＣＰＵ１１１は、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止し、割込み処理タスク５００を実行する。

次に、割込み処理タスクの終了時の処理を説明する。図１７は、本実施形態の割込み処理タスク５００終了時の処理の例を示すフローチャートである。

まずステップＳ１４０１において、ＣＰＵ１１１は、割込み処理タスク５００を第１ＯＳタスク１６０のレディキューから外し、休止状態に遷移させる。次にステップＳ１４０２において、ＣＰＵ１１１は第１ＯＳタスク１６０のディスパッチ処理を実行する。ディスパッチ処理により実行状態となったタスクに対応した割込み許可および禁止の状態にするために、ステップＳ１４０３において、ＣＰＵ１１１はデバッグ対象マルチタスクシステムの割込み許可／禁止設定処理を実行し、実行状態となったタスクを実行する。

以上のように割込み処理を１つのタスクとして、第１ＯＳタスク１６０で管理し、仮想割込み制御プログラム５１０によって、デバッグ対象マルチタスクシステムのタスク（タスク１５１，１５２）より優先的に割込み処理タスク５００を実行する。優先度を設定できるため、割込み処理タスク５００を優先して実行することが可能となる。

次に、本実施形態におけるデバッグ対象マルチタスクシステム１５０のタスク（タスク１５１および１５２）および割込み処理タスク５００を停止する処理を説明する。

デバッグ対象マルチタスクシステム１５０のタスク（タスク１５１またはタスク１５２）を停止する処理は、実施形態１と同様に、マルチタスクシステムを構成する任意のタスクがブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止する。

デバッグ対象マルチタスクシステム１５０の割込み処理においても、割込み処理タスク５００として第１ＯＳタスク１６０でタスクとして管理されるので、通常のタスク（タスク１５１またはタスク１５２）同様にブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止することにより、デバッグ対象マルチタスクシステム１５０を停止する。

次に本実施形態による仮想割込み処理の動作例を説明する。この例は、タスク１４１が実行中であり、割込み処理タスクは起動していないときの仮想割込み処理の動作例である。また、第２ＯＳ１３０が管理しているタスクの優先度を
タスク１４１（優先度２）＞タスク１４２（優先度３）＞第１ＯＳタスク１６０（優先度４）
とし、また、第１ＯＳタスク１６０が管理するタスクの優先度を
割込み処理タスク５００（優先度１）＞タスク１５１（優先度２）＞タスク１５２（優先度３）
とする。

図１８は、デバッグ対象マルチタスクシステム１５０の割込みが発生した場合における、タスクの遷移のタイミングを示す。また、図１９は、割込み処理タスクの起動処理および終了処理における、第１ＯＳタスク１６０および第２ＯＳ１３０のレディキューの状態を示す。

デバッグ対象マルチタスクシステム１５０の割込みが発生した場合の動作を説明する。

デバッグ対象マルチタスクシステムの割込みが発生する（図１８の１５０１、図１９（ａ））と、ＣＰＵ１１１は制御を仮想割込み制御プログラム５１０の割込み判定処理に切り替える。そして、レジスタ退避、スタックの切替などの前処理（ステップＳ６０１）を行う。次に、割込み処理タスクの起動対象の割込みであるか否かを判定する（ステップＳ６０２）。この例の割込みは、割込み処理タスクの起動対象の割込みである。よってＣＰＵ１１１は、割込み処理タスクの起動処理を実行する（ステップＳ６０５）。

まず、割込み処理タスク５００を起動するために、第１ＯＳタスク１６０に割込み処理タスク５００のタスク起動のシステムコールを発行する（ステップＳ１２０１、図１９（ｂ））。次に、第１ＯＳタスクが実行中であるか確認する（ステップＳ１２０２）。第１ＯＳタスクが実行中でないので、第１ＯＳタスク１６０がディスパッチされた後に割込み処理タスク５００をディスパッチするために、割込み処理タスクの起動要求を設定する（ステップＳ１２０５）。次に、レジスタの復帰などの後処理を実行し（ステップＳ１２０６）、割込みから復帰し、タスク１４１を実行する（図１８の１５０２）。タスク１４１が終了すると（図１８の１５０３）、第２ＯＳのディスパッチ処理が実行される。

まず、第２ＯＳのタスクスケジューリングを実行し（ステップＳ１３０１）、タスク１４２が実行状態となる（図１９（ｃ））。実行状態のタスクが第１ＯＳタスクであり、かつ、割込み処理タスクの起動要求があるかどうかを判定する（ステップＳ１３０２）。第１ＯＳタスクでないので、実行状態となったタスク１４２を実行する（図１８の１５０４）。タスク１４２が終了すると（図１８の１５０５）、第２ＯＳのディスパッチ処理が実行される。第２ＯＳのタスクスケジューリングを実行し（ステップＳ１３０１）、第１ＯＳタスクが実行状態となる（図１９（ｄ））。実行状態のタスクが第１ＯＳタスクであり、かつ、割込み処理タスクの起動要求があるかどうかを判定する（ステップＳ１３０２）。第１ＯＳタスクであり、かつ、割込み処理タスクの起動要求があるので、第１ＯＳのディスパッチ処理を実行する（ステップＳ１３０３）。これにより、割込み処理タスク５００がディスパッチされる。さらに、デバッグ対象マルチタスクシステム１５０のすべての割込みを禁止し（ステップＳ１３０４）、割込み処理タスク５００を実行する（図１８の１５０６）。

割込み処理タスク５００が終了すると（図１８の１５０７）、まず、割込み処理タスク５００を第１ＯＳタスク１６０のレディキューから外し、休止状態に遷移させる（ステップＳ１４０１、図１９（ｅ））。次に、第１ＯＳタスク１６０のディスパッチ処理を実行することにより（ステップＳ１４０２）、タスク１５１が実行状態となる。タスク１５１の割込み状態に応じて、デバッグ対象マルチタスクシステム１５０の割込み設定を行い（ステップＳ１４０３）、実行状態となったタスク１５１を実行する（図１８の１５０８）。これにより、実施形態２によるデバッグシステムと同様の効果を得ることができる。

上述のように、デバッグ対象マルチタスクシステム１５０を第１ＯＳタスク１６０で管理し、デバッグ対象マルチタスクシステムを構成する任意のタスク（タスク１５１またはタスク１５２）がブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止することにより、デバッグ対象マルチタスクシステム１５０を構成するすべてのタスク（タスク１５１およびタスク１５２）に関し、その実行環境を保持した状態で実行を抑制することが可能となる。また、デバッグ対象マルチタスクシステム１５０の停止中に、他の実行中のタスクなどによるタスクの状態を変化させるようなシステムコールが第２ＯＳ１３０に対して発行されても、第１ＯＳ１６０で管理されているデバッグ対象マルチタスクシステム１５０のタスク１５１および１５２には影響を与えず、デバッグを容易化できる。

さらに、割込み処理同等の動作をさせる仮想割込み処理によって、デバッグ対象マルチタスクシステムの割込み処理を第１ＯＳタスク１６０で管理し、ブレークポイントに到達した時点あるいは例外が発生した時点で、第１ＯＳタスク１６０の実行を停止することにより、デバッグ対象マルチタスクシステム１５０を構成するすべてのタスク（タスク１５１およびタスク１５２）および割込み処理５００に関し、その実行環境を保持した状態で実行を抑制することが可能となる。これにより、割込み処理を含むマルチタスクシステム全体のデバッグが可能となり、デバッグを容易化できる。

本実施形態においては、ターゲットシステム１１０が２つのマルチタスクシステム１４０と１５０で構成される例で説明したが、３つ以上のマルチタスクシステムで構成される場合にも本発明は適用可能である。また、各マルチタスクシステム１４０と１５０においてもタスク数をそれぞれ２つで構成される例で説明したが、各マルチタスクシステム１４０と１５０の一方、または、双方が３つ以上のタスクで構成される場合にも本発明は適用可能である。また、デバッグ対象マルチタスクシステム１５０の割込み処理数が１つで構成される例で説明したが、２つ以上の割込み処理で構成される場合にも本発明は適用可能である。

本実施形態においては、非デバッグ対象のマルチタスクシステム１４０は第２ＯＳ１３０で管理されるが、第２ＯＳ１３０で管理されるＯＳタスクで管理してもよい。また、非デバッグ対象のマルチタスクシステムが２つ以上ある場合においても、各非デバッグ対象のマルチタスクシステムをＯＳタスクで管理し、各ＯＳタスクを第２ＯＳ１３０で管理してもよい。

なお、本実施形態では、割込み処理タスクの起動処理内の割込み禁止処理（図１５のステップＳ１２０４）、第２ＯＳディスパッチ処理の割込み禁止処理（図１６のステップＳ１３０４）、および、割込み処理タスク終了処理の割込み許可／禁止処理（図１７のステップＳ１４０３）において、デバッグ対象マルチタスクシステム１５０のすべての割込みを許可および禁止する例を挙げて説明した。しかし、デバッグ対象マルチタスクシステム１５０およびマルチタスクシステム１４０のすべての割込みを許可および禁止してもよい。

本発明によれば、複数のタスクと割込み処理で構成されるマルチタスクシステムを複数並行実行するプログラムのデバッグに有用な方法および装置が得られる。本発明によるマルチタスクシステムのプログラムデバッグ方法とその装置は、デバッグ対象マルチタスクシステムを構成する任意のタスクおよび割込み処理がブレークポイントに到達した時点あるいは例外が発生した時点で、デバッグ対象マルチタスクシステムを構成するすべてのタスクおよび割込み処理に関し、その実行環境を保持した状態で実行を抑制する。また、デバッグ対象マルチタスクシステム停止中に、他の実行中のタスクからタスクの状態を変化させるシステムコールが発行されても、デバッグ対象マルチタスクシステムのタスクは影響を受けない。これにより、マルチタスクシステムのデバッグが容易になる。

実施形態１によるデバッグ機能によって開発された第１の光ディスクシステムの構成を示す図である。 実施形態によるデバッグ機能によって開発された第２の光ディスクシステムの構成を示す図である。 複合型マルチタスクシステムが構築された大規模半導体集積回路（ＬＳＩ）１０９の構成を示す図である。 実施形態１における、デバッグシステムの全体構成を示す概略図である。 ＣＰＵ１１１と割込み制御装置１１２の詳細な構成図である。 デバッグ対象マルチタスクシステムを停止する処理例を示すフローチャートである。 デバッグ対象マルチタスクシステムを再開する処理例を示すフローチャートである。 実施形態２における、デバッグシステムの全体構成を示す概略図である。 割込みを判定する処理例を示すフローチャートである。 実施形態２における、割込み処理タスクを起動する処理例を示すフローチャートである。 実施形態２における、割込み処理タスク終了時の処理例を示すフローチャートである。 実施形態２における、割込みが発生した場合におけるタスクの遷移のタイミング図である。 実施形態２における、第１ＯＳタスクおよび第２ＯＳのレディキューの状態を示す図である。 非デバッグ対象のマルチタスクシステムをＯＳタスクで管理した場合のタスク構成図である。 実施形態３における、割込み処理タスクを起動する処理例を示すフローチャートである。 実施形態３における、第２ＯＳのタスクディパッチ処理の処理例を示すフローチャートである。 実施形態３における、割込み処理タスク終了時の処理例を示すフローチャートである。 実施形態３における、割込みが発生した場合におけるタスクの遷移のタイミング図である。 実施形態３における、第１ＯＳタスクおよび第２ＯＳのレディキューの状態を示す図である。 従来の光ディスクシステムの概略的な構成を示す図である。

符号の説明

１１０ ターゲットシステム
１１１ ＣＰＵ
１１２ 割込み制御装置
１１３ 実メモリ
１２０ モニタプログラム
１３０ 第２ＯＳ
１４０ マルチタスクシステム
１４１ タスク
１４２ タスク
１５０ デバッグ対象マルチタスクシステム
１５１ タスク
１５２ タスク
１６０ 第１ＯＳ（タスク）
１７０ ホストコンピュータ
１８０ デバッガ
１９０ インタフェースバス
２００（１）〜２００（ｎ） 割込みグループ制御部
５００ 割込み処理
５１０ 仮想割込み制御プログラム
１１１０ 第３のＯＳ

Claims (14)

1. デバッガプログラムを実行するホストコンピュータと、
   前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムが構築された回路と
   を含むデバッグシステムであって、
   前記回路は、プログラムが格納されたメモリ、および、前記メモリ上のプログラムを実行可能な処理部を備えており、
   前記メモリは、
   前記第１マルチタスクシステムの１以上のタスクプログラムを管理する第１オペレーティングシステムと、
   前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納する、デバッグシステム。
2. 前記メモリには、前記第１マルチタスクシステムの実行を制御するためのモニタプログラムがさらに格納されており、
   前記処理部は、前記デバッガプログラムを実行した前記ホストコンピュータからのコマンドに応答して前記モニタプログラムを実行し、前記コマンドに応じた処理を実行して、前記ホストコンピュータに応答を返す、請求項１に記載のデバッグシステム。
3. 前記メモリは、前記第２オペレーティングシステムおよび前記１以上の第２タスクプログラムを、前記第２マルチタスクシステムとして格納する、請求項１に記載のデバッグシステム。
4. 前記メモリは、前記１以上の第２タスクプログラムとして、第３オペレーティングシステムおよび前記第３オペレーティングシステムによって管理される第３タスクプログラムを格納し、
   前記第３オペレーティングシステムおよび前記第３タスクプログラムを、前記第２マルチタスクシステムとして格納する、請求項１に記載のデバッグシステム。
5. 前記回路はスタックをさらに備え、
   前記処理部は、前記第１マルチタスクシステムの実行環境を前記スタックに退避し、その後、前記モニタプログラムに基づいて、前記第１マルチタスクシステムに含まれる１以上のタスクプログラムの実行を停止する、請求項２に記載のデバッグシステム。
6. 前記処理部は、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止する際に、前記第１オペレーティングシステムを停止状態に遷移させる、請求項５に記載のデバッグシステム。
7. 前記処理部は、処理が予め設定されたブレークポイントに到達すると、前記第１オペレーティングシステムを停止状態に遷移させて、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止する、請求項６に記載のデバッグシステム。
8. 前記処理部は、処理に例外が発生すると、前記第１オペレーティングシステムを停止状態に遷移させて、前記第１マルチタスクシステムに含まれるタスクプログラムの実行を停止する、請求項６に記載のデバッグシステム。
9. 前記処理部は、前記第１オペレーティングシステム上で、前記第１マルチタスクシステムの割込み処理を実行可能であり、前記割込み処理を前記第１マルチタスクシステムのいずれのタスクプログラムよりも優先して実行する、請求項１に記載のデバッグシステム。
10. 前記処理部は、前記第１オペレーティングシステム上で、前記第１マルチタスクシステムの割込み処理を実行可能であり、前記割込み処理を前記複合システムのいずれのタスクプログラムより優先して実行する、請求項１に記載のデバッグシステム。
11. 前記処理部によって実行される前記第１オペレーティングシステムは、前記割込み処理を割込みタスクプログラムとして管理しており、
    前記処理部は、前記割込みタスクプログラムを前記第１マルチタスクシステムのいずれのタスクプログラムより優先して実行する、請求項９に記載のデバッグシステム。
12. 前記処理部によって実行される前記第１オペレーティングシステムは、前記割込み処理を割込みタスクプログラムとして管理しており、
    前記処理部は、前記割込みタスクプログラムを前記複合システムのいずれのタスクプログラムより優先して実行する、請求項１０に記載のデバッグシステム。
13. デバッガプログラムを実行するホストコンピュータと接続され、前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムが構築された回路であって、
    前記回路は、プログラムが格納されたメモリと、前記メモリ上のプログラムを実行可能な処理部とを備え、
    前記メモリは、
    前記第１マルチタスクシステムの１以上のタスクプログラムを管理する第１オペレーティングシステムと、
    前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納する、回路。
14. デバッガプログラムを実行するホストコンピュータと接続され、前記デバッガプログラムによってデバッグされる第１マルチタスクシステム、および、非デバッグ対象の第２マルチタスクシステムを有する複合システムを構築することが可能な回路であって、
    前記回路は、プログラムが格納されたメモリと、前記メモリ上のプログラムを実行可能な処理部とを備え、
    前記メモリは、第１オペレーティングシステムと、
    前記第１オペレーティングシステムを第１タスクプログラムとして管理し、かつ、前記第１タスクプログラムとは異なる１以上の第２タスクプログラムを管理する第２オペレーティングシステムとを格納しており、
    前記第１オペレーティングシステムは、前記メモリに１以上のタスクプログラムが読み込まれたとき、前記１以上のタスクプログラムを前記第１マルチタスクシステムのタスクプログラムとして管理する、回路。
    
    
    

Images