JP2001134463A

JP2001134463A - ソフトウェア走行履歴モニタ方法

Info

Publication number: JP2001134463A
Application number: JP31384199A
Authority: JP
Inventors: Kenji Fujizono; 賢治藤園
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1999-11-04
Filing date: 1999-11-04
Publication date: 2001-05-18

Abstract

(57)【要約】【課題】ソフトウェア走行履歴モニタ方法に関し、２
階層からなるプロセッサシステムで２次側バスでプログ
ラムの走行情報を収集することを目的とする。【解決手段】アプリケーションプログラム１７が起動
の際に、メインメモリ１２上に走行中のプログラムを識
別するタスク番号を格納する固定エリアが決められ、ア
プリケーションプログラム１７がオペレーティングシス
テム１８へのサブルーティンコールは、固定エリアにタ
スク番号をセーブした上で行う。オペレーティングシス
テム１８は固定エリアからタスク番号を取得し、アドレ
ス情報フィールドの空きフィールドにタスク番号を付与
し、そのアドレス情報で入出力デバイス１６に対してア
クセスする。低速バス１５に現れたアドレス情報を測定
器１９がモニタし、そのタスク番号から走行中のプログ
ラムが属するモジュール（またはタスク）を識別でき
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はソフトウェア走行履
歴モニタ方法に関し、特に内部高速プロセッサバスと外
部汎用低速バスとで構成されるプロセッサシステムで走
行するソフトウェアの履歴をモニタするソフトウェア走
行履歴モニタ方法に関する。

【０００２】プロセッサシステムまたはそのプロセッサ
システム上で走行するソフトウェアにおいて、その開発
段階または障害発生時の調査段階で、ソフトウェアのプ
ログラムがプロセッサシステムでどのように動いている
かの概略を把握することによって、プログラムのデバッ
グ作業または障害発生の原因究明を迅速に行うことが可
能となる。

【０００３】

【従来の技術】図１８はプロセッサシステムの構成例を
示す図である。このプロセッサシステムにおいて、プロ
セッサシステムのコアとなるマイクロプロセッサ（ＭＰ
Ｕ：micro processing unit）１は、内部プロセッサバ
ス（１次側バス）によって、システムバスコントローラ
２と、バスブリッジ３と、クロスバスイッチ４とに接続
されている。内部プロセッサバスは、マイクロプロセッ
サ１とクロスバスイッチ４とを接続するプロセッサデー
タバスと、クロスバスイッチ４とバスブリッジ３とを接
続するＩＯ（Input/Output）データバスと、マイクロプ
ロセッサ１とシステムバスコントローラ２とバスブリッ
ジ３とを接続するアドレス信号線と、システムバスコン
トローラ２とマイクロプロセッサ１、バスブリッジ３お
よびクロスバスイッチ４とを接続する制御信号線とから
構成される。クロスバスイッチ４は、また、メモリデー
タバスによってメインメモリ５に接続されている。バス
ブリッジ３は、外部汎用バス（２次側バス）であるＰＣ
Ｉ（Peripheral Component Interconnect）バス６に接
続され、このＰＣＩバス６には、ＳＣＳＩ（Small Comp
uter System Interface）バスコントローラ７、ＬＡＮ
（Local Area Network）コントローラ８などが接続され
ている。ＳＣＳＩバスコントローラ７にはハードディス
ク７ａ、ＭＯ（Magneto-Optical）ディスクドライブ７
ｂなどのＳＣＳＩ機器が接続され、ＬＡＮコントローラ
８にはＬＡＮケーブルを介して外部のワークステーショ
ン８ａなどに接続されている。

【０００４】以上のプロセッサシステムの構成におい
て、マイクロプロセッサ１の直下にある上位側は、内部
プロセッサバスにて動作し、周辺機器が接続される下位
側は、外部汎用バスであるＰＣＩバス６にて動作すると
いう２階層の構成になっている。

【０００５】ここで、一般的にソフトウェアをデバッグ
する場合、ソフトウェアの走行履歴を確認しながらデバ
ッグを行うが、その走行履歴を確認する方法としてソフ
トウェアで行う方法と、ハードウェアで行う方法とがあ
る。まず、ソフトウェアの走行履歴をハードウェアで確
認する方法について説明する。

【０００６】図１９はハードウェアによるソフトウェア
の走行履歴確認の一例を示す図である。なお、図１８に
示した要素と同じ要素については同じ符号を付してその
説明は省略する。

【０００７】ハードウェア的にソフトウェアの走行履歴
をモニタする場合、測定器９がマイクロプロセッサ直下
の内部プロセッサバスに直接装着される。この測定器９
としては、たとえばロジックアナライザ、インサーキッ
トエミュレータなどが使われる。ソフトウェアの走行時
に、測定器９がバスの動作状態をモニタする。具体的に
は、測定器９を使ってバス上のアドレス／データ情報を
モニタする。その情報でソフトウェアの走行履歴を確認
することができるので、正しいプログラム走行がなされ
ているか否かの判定が可能になる。

【０００８】ところで、近年のマイクロプロセッサシス
テムでは、マイクロプロセッサ１の動作周波数の向上に
伴い、マイクロプロセッサ直下の内部プロセッサバスの
動作周波数も格段に高くなってきた。このため、内部プ
ロセッサバスへの測定器９の装着が電気的な特性劣化を
引き起こし、確認すべきバス動作が正常に動作しなくな
る可能性が高くなってきている。具体的には、測定器９
の装着は各信号線の負荷容量（コンデンサ成分）を増加
させ、信号のライズタイム／フォールタイムの悪化（波
形なまり）を引き起こし、各ＬＳＩ（Large Scale Inte
grated circuit）のロジック回路が誤動作することにな
る。つまり、正確なプログラム走行トレースが非常に困
難になってきている。

【０００９】また、マイクロプロセッサメーカとしての
ユーザへの供給形態がマイクロプロセッサ単体での供給
ではなく、マイクロプロセッサがＰＣＩバスのような汎
用インタフェース部分で隠蔽された形態、つまりマイク
ロプロセッサと上位の内部プロセッサバスとが作り込ま
れた形態となってきている。このため、下位の低速バス
側からは上位の内部プロセッサバスの動作、すなわちプ
ログラム走行情報を観測することができなくなってきて
いる。さらに、プロセッサ開発サイクルの短期化に伴
い、エミュレータメーカの開発が追い付かず、新規プロ
セッサに対応したエミュレーション装置がシステム開発
時には存在しないのが現状である。

【００１０】このように、一般のユーザ（システムメー
カ）は、マイクロプロセッサコア部分のハードデバッグ
作業からは開放されたが、ハード開発時はもとより、障
害調査やソフトデバッグ時にソフトウェアの走行状況、
すなわち内部プロセッサバスの動作状況をハードウェア
的に把握することが困難になってきた。

【００１１】一方、ソフトウェアによる走行履歴の確認
方法としては、走行のマイルストーン的なアドレス（走
行するであろうと予測されるプログラムの先頭命令の格
納アドレスなど）に本来の命令ではなくトラップ命令を
挿入し、そのアドレスまで到達したならトラップ命令に
より割り込みを上げてプログラムを停止させる。走行予
測アドレスを設定しては走らせ、新たな（次のマイルス
トーン）アドレスを設定しては走らせ、という手順を繰
り返すことでソフトウェアの走行履歴を確認し、正しい
プログラム走行がなされているか否かを判断し、プログ
ラム上の問題点（予測外の誤ったルートの命令実行）を
ローカライズする。

【００１２】

【発明が解決しようとする課題】しかし、ソフトウェア
による走行履歴の確認方法は、命令実行を誤っているポ
イント、すなわち命令格納アドレスが推測できて初めて
調査が可能となるものであり、そのポイントが絞られて
いない場合は、ソフトウェアの問題が発生しているアド
レスを解析することは不可能であるという問題点があっ
た。

【００１３】本発明はこのような点に鑑みてなされたも
のであり、複数階層からなるプロセッサシステムで２次
側、もしくはそれ以下の階層のバスでプログラムの走行
情報を収集するための新たな方法を提供することを目的
とする。

【００１４】

【課題を解決するための手段】図１は上記目的を達成す
る本発明の原理図である。ソフトウェアの走行履歴モニ
タの対象となるプロセッサシステム１０において、マイ
クロプロセッサ１１とメインメモリ１２とが内部プロセ
ッサバスと呼ばれる上位の高速バス１３によって接続さ
れ、この高速バス１３はバスブリッジ１４を介して外部
汎用バスと呼ばれる下位の低速バス１５に接続され、そ
の低速バス１５に入出力デバイス１６が接続されてい
る。

【００１５】このように、バス構成が２階層になってい
るプロセッサシステム１０において、アプリケーション
プログラム１７が起動の際に、メインメモリ１２に対し
て走行中のプログラムを識別する情報であるタスク番号
を格納するための固定エリアが決められる。アプリケー
ションプログラム１７がオペレーティングシステム１８
のサブルーティンコールをする場合、アプリケーション
プログラム１７はメインメモリ１２の固定エリアにタス
ク番号をセーブした上でオペレーティングシステム１８
のプログラムをコールする。コールされたオペレーティ
ングシステム１８はメインメモリ１２の固定エリアをリ
ードし、タスク番号を取得する。オペレーティングシス
テム１８が入出力デバイス１６に対してアクセスする際
に、アドレス情報フィールドの空きフィールドに取得し
たタスク番号を付与し、そのアドレス情報でデバイスア
クセスを行う。これにより、入出力デバイス１６が接続
された低速バス１５には、タスク番号が挿入されたアド
レス情報が現れるので、この低速バス１５上のアドレス
情報を測定器１９がモニタすることにより、アドレス情
報のタスク番号から走行中のプログラムが属するモジュ
ール（またはタスク）を識別することができる。この結
果、ソフトウェアの問題が発生しているような場合に、
下位の低速バス１５から取得したアドレス情報を解析す
ることで障害発生の原因を究明することができ、デバッ
グ作業を迅速に行うことができるようになる。

【００１６】また、本発明によれば、アプリケーション
プログラムが起動の際にメインメモリに対して所定のエ
リアの割り付けを行うメモリ割り付け手段と、前記アプ
リケーションプログラムがオペレーティングシステムを
コールする際に前記メインメモリの所定のエリアに走行
中のプログラムを識別するプログラム識別情報を格納す
る格納手段とを有するソフトウェア走行履歴情報設定プ
ログラムを記録したコンピュータ読み取り可能な記録媒
体が提供される。

【００１７】この媒体に記録されたソフトウェア走行デ
ータ設定プログラムをコンピュータに実行させることに
より、メモリ割り付け手段と、格納手段との各機能がコ
ンピュータによって実現できる。

【００１８】

【発明の実施の形態】まず、本発明の概略について図面
を参照して説明する。図１は本発明によるソフトウェア
走行履歴モニタ方法の原理説明図である。ソフトウェア
の走行履歴モニタの対象となるプロセッサシステム１０
において、マイクロプロセッサ１１とメインメモリ１２
とが内部プロセッサバスと呼ばれる上位の高速バス１３
によって接続され、この高速バス１３はバスブリッジ１
４を介して外部汎用バスと呼ばれる下位の低速バス１５
に接続され、その低速バス１５に入出力デバイス１６が
接続されている。

【００１９】このように、バス構成が２階層になってい
るプロセッサシステム１０において、アプリケーション
プログラム１７が起動の際に、メインメモリ１２に対し
て走行中のプログラムを識別する情報であるタスク番号
を格納するための固定エリアが決められる。アプリケー
ションプログラム１７がオペレーティングシステム１８
のサブルーティンコールをする場合、アプリケーション
プログラム１７はメインメモリ１２の固定エリアにタス
ク番号をセーブした上でオペレーティングシステム１８
のプログラムをコールする。コールされたオペレーティ
ングシステム１８はメインメモリ１２の固定エリアをリ
ードし、タスク番号を取得する。オペレーティングシス
テム１８が入出力デバイス１６に対してアクセスする際
に、アドレス情報フィールドの空きフィールドに取得し
たタスク番号を付与し、そのアドレス情報でデバイスア
クセスを行う。これにより、入出力デバイス１６が接続
された低速バス１５には、タスク番号が挿入されたアド
レス情報が現れるので、この低速バス１５上のアドレス
情報を測定器１９がモニタすることにより、アドレス情
報のタスク番号から走行中のプログラムが属するモジュ
ール（またはタスク）を識別することができる。この結
果、ソフトウェアの問題が発生しているような場合に、
下位の低速バス１５から取得したアドレス情報を解析す
ることで障害発生の原因を究明することができ、デバッ
グ作業を迅速に行うことができるようになる。

【００２０】次に、本発明の第１の実施の形態を、２階
層のバス構成を有する、交換機用のプロセッサシステム
に適用した場合を例にして説明する。図２はプロセッサ
システムへの測定器の設置例を示す図である。ここで、
プロセッサシステムは、汎用のマイクロプロセッサ（Ｍ
ＰＵ）２１と、システムバスコントローラ（ＳＣ）２２
と、クロスバスイッチ（ＸＢ１／ＣＢＴ）２３と、メイ
ンメモリ（ＭＭ）２４と、バスブリッジ（Ｕ２Ｐ）２５
とを備えている。マイクロプロセッサ２１は、たとえば
３００−４００ＭＨｚ動作の米国ＳＵＮ製ＵｌｔｒａＳ
ＰＡＲＣ２（ＳＰＡＲＣは、米国 SPARC Internationa
l, Inc. のライセンスを受けて使用している同社の米国
およびその他の国における商標または登録商標）とする
ことができる。マイクロプロセッサ２１、システムバス
コントローラ２２、クロスバスイッチ２３およびバスブ
リッジ２５は、内部プロセッサバスによって相互に接続
され、クロスバスイッチ２３およびメインメモリ２４は
たとえば２５６ビットのメモリデータバスによって接続
されている。内部プロセッサバスは、マイクロプロセッ
サ２１とクロスバスイッチ２３とを接続するたとえば１
２８ビットのプロセッサデータバスと、クロスバスイッ
チ２３とバスブリッジ２５とを接続するたとえば６４ビ
ットのＩＯデータバスと、システムバスコントローラ２
２とマイクロプロセッサ２１およびバスブリッジ２５と
を接続するアドレス信号線と、システムバスコントロー
ラ２２とマイクロプロセッサ２１、クロスバスイッチ２
３およびバスブリッジ２５とを接続する制御信号線とか
らなっている。バスブリッジ２５はＰＣＩバス２６に接
続され、ＰＣＩバス２６はＳＣＳＩバスコントローラ
（ＳＰＣ）２７、ＬＡＮコントローラ（ＬＡＮＣ）２８
などが接続される。ＳＣＳＩバスコントローラ２７に
は、たとえばハードディスク２７ａ、ＭＯディスクドラ
イブ２７ｂが接続され、ＬＡＮコントローラ２８には、
たとえばワークステーション２８ａが接続されている。

【００２１】マイクロプロセッサ２１直下の内部プロセ
ッサバスは内部高速プロセッサバス（１次側バス）に該
当し、たとえば１００ＭＨｚで動作する。一方、ＰＣＩ
バス２６は外部汎用低速バス（２次側バス）に該当し、
３３ＭＨｚで動作する。

【００２２】このように、プロセッサバス側はプロセッ
サメーカにより作り込まれているため、システムのハー
ドウェア的な構成については、システムメーカによる改
良の余地はない。測定器３０は、外部汎用低速バスであ
る下位のＰＣＩバス２６に接続される。

【００２３】ここで、ソフトウェアの走行履歴情報とす
るモジュール（またはタスク）番号を、デバイスへのア
クセスにおけるアドレス情報へ挿入する方法について説
明する。

【００２４】以上のプロセッサシステムにおいて、プロ
グラムが走行する場合（命令実行が行われる場合）、内
部プロセッサバスの中だけにクローズした動きで完結し
ているわけではなく、常に、２次側のバス（ここではＰ
ＣＩバス２６）上のＬＳＩや装置に対してのデータリー
ド／ライトの動作が発生する。たとえばハードディスク
２７ａやＭＯディスクドライブ２７ｂへのデータアクセ
ス、ＬＡＮコントローラ２８への通信設定などといった
各種アクセスが存在する。

【００２５】図３はＰＣＩバスのリードサイクル／ライ
トサイクルについてのタイムチャートを示す図である。
２次側バス上のデバイスは、システム上でマッピングさ
れたユニークなアドレスを有しており、アクセスはアド
レス情報とリード／ライト種別とを内部プロセッサバス
から２次側のＰＣＩバス２６を経由して各デバイスに供
給され、各デバイスはそのＰＣＩバス２６上の情報をも
とに、リード要求であれば該当アドレスのデータをＰＣ
Ｉバス２６上に送出し、ＰＣＩバス２６から内部プロセ
ッサバスを経由してマイクロプロセッサ２１に返送され
る。ライトであれば、アドレス情報とリード／ライト種
別とともにライトデータをデバイスに供給し、デバイス
はその該当アドレスにデータを格納する。ＰＣＩバス２
６上には、リード／ライトのいずれにも、アドレスサイ
クルが必ず現れて、デバイスを決定するためのサイクル
が存在する。

【００２６】具体的には、ライトサイクルの場合、クロ
ック信号ＣＬＫに同期して内部プロセッサバスからアド
レスサイクルを識別するＦＲＡＭＥ信号とアドレス情報
とをＰＣＩバス２６上に出す。デバイスは、ＦＲＡＭＥ
信号がローレベルに落ちているところでアドレスが有効
であると判断して、そのアドレス情報を取り込む。取り
込んだアドレス情報からライトを判断して、内部プロセ
ッサバスからのデータの有効期間を表すＩＲＤＹ信号に
従ってアドレス情報に後続するデータを取り込むことに
なる。このとき、上位の内部プロセッサバス側に対して
アクセスサイクルの終わりを表すＴＲＤＹ信号を返す。

【００２７】リードサイクルの場合は、クロック信号Ｃ
ＬＫに同期して内部プロセッサバスからアドレスサイク
ルを識別するＦＲＡＭＥ信号とアドレス情報とをＰＣＩ
バス２６上に出す。デバイスは、ＦＲＡＭＥ信号がロー
レベルに落ちているところでアドレスが有効であると判
断して、そのアドレス情報を取り込む。次に、内部プロ
セッサバスからは内部プロセッサバスからのデータ受け
取り可能を表すＩＲＤＹ信号が出され、デバイスからの
ＴＲＤＹ信号がローレベルになったところがデータ有効
と判断し、内部プロセッサバス側がこのデータを取り込
んで、リードサイクルが終了する。

【００２８】測定器３０がＰＣＩバス２６をモニタした
ときには、測定器３０はこのタイムチャートに示したよ
うな信号波形をモニタすることができ、中でも、このタ
イムチャートの中の各アドレス情報をモニタすること
で、アドレス情報に挿入されたソフトウェアの走行履歴
情報を得ることができる。

【００２９】図４はアドレス情報のビットフィールドを
示す図であって、（Ａ）は内部プロセッサバスアドレス
ビットフィールドを示し、（Ｂ）はＰＣＩバスアドレス
ビットフィールドを示している。内部プロセッサバスア
ドレスビットフィールドは、４１ビットからなり、ここ
で、４０−３１ビットのフィールドに内部プロセッサバ
ス上の装置を指示する中継アドレスが、３０−２４ビッ
トのフィールドにＰＣＩバス上の装置アドレスが、そし
て、１５−０ビットのフィールドにＰＣＩバス上の装置
内レジスタアドレスがそれぞれ割り当てられている。４
０−３１ビットの中継アドレスはバスブリッジがＰＣＩ
バスへの中継判定を行うのに使用され、３０−２４ビッ
トの装置アドレスはＰＣＩバス上の装置が自分へのアク
セスか否かの判定を行うのに使用される。なお、以上の
ビットフィールド以外の２３−１６ビットのビットフィ
ールドは空いている。また、デバイス側もこの空きフィ
ールドについては無視することにしている。

【００３０】本発明の第１の実施の形態では、このアド
レス情報の空きフィールドを利用し、ここにプログラム
のモジュール情報やタスク情報を入れることにし、この
アドレス情報に挿入されたプログラムのモジュール情報
やタスク情報を測定器３０でモニタし、情報収集するこ
とによりプログラムの走行履歴の確認と異常ルート（異
常モジュールや異常タスク）走行の検出を行うことを可
能とする。

【００３１】また、バスブリッジを通ってＰＣＩバス上
に現れるＰＣＩバスアドレスビットフィールドは、
（Ｂ）に示したように、（Ａ）に示した内部プロセッサ
バスアドレスビットフィールドから４０−３１ビットの
ビットフィールドが削除された形になっている。

【００３２】図５はプロセッサシステムのアドレスマッ
ピングの例を示す図である。システムのアドレスは、採
用するマイクロプロセッサによって決まり、この例はマ
イクロプロセッサが"ＵｌｔｒａＳＰＡＲＣ２"であるの
で、そのシステムアドレスは４１ビットからなり、上位
９ビットで大きく内部プロセッサバスの装置アドレスが
割り当てられている。さらに、一番下の空間は、バスブ
リッジ（Ｕ２Ｐ）に割り当てられた空間であり、配下の
ＰＣＩバス上のデバイスごとにアドレス範囲が割り付け
られ、そのデバイスのアドレス範囲の中で最終的に各デ
バイスの個々のレジスタのアドレスが割り付けられてい
る。したがって、マイクロプロセッサがＰＣＩバス上の
あるデバイスにアクセスするときは、一番下の空間（PC
I-B MEMspace）の決められたアドレスに命令を実行して
アクセスすることになる。この空間へのアクセスはバス
ブリッジによりＰＣＩバス上に中継される。

【００３３】図６はモニタの概要を示す図である。図示
のように、マイクロプロセッサ２１がメインメモリ２４
に展開されたプログラムをリードして実行することでソ
フトウェアが走行する（矢印３１）。プログラムの命令
解析・実行は内部プロセッサバス上で行われるため、そ
のソフトウェアの走行履歴は内部プロセッサバスをモニ
タすることでしか取得する方法はない。しかし、マイク
ロプロセッサ２１の動きの中で必ず存在するＰＣＩバス
２６上のデバイス（ＳＣＳＩバスコントローラ２７、Ｌ
ＡＮコントローラ２８）へのライト／リードのアクセス
（矢印３２）がある。本発明の第１の実施の形態では、
ＰＣＩバス２６へ出てくる各ＰＣＩバス２６上のデバイ
スに対してのライト／リードアクセスサイクルを測定器
３０でモニタすることで、内部の実行プログラムの情報
を得ることになる。

【００３４】次にアドレスの空きビットヘモジュール情
報（タスク情報）を挿入する仕組みについて説明する。
図７はソフトウェアの概念的な構成を示す図である。一
般に、システム全体の構成としては、一番下にハードウ
ェア／ファームウェア４１があり、その上にオペレーテ
ィングシステム（ＯＳ）４２がある。このオペレーティ
ングシステム４２には、基本的なシステム制御であると
か、ＬＡＮドライバ、ハードディスクドライバなどのデ
バイスドライバ、その他、各種システム運用上のプログ
ラムなどが入っている。そのオペレーティングシステム
４２の上には、各種アプリケーションプログラム（ＡＰ
Ｌ）４３が存在する。したがって、ソフトウェアの構成
は、ハードウェア／ファームウェア４１とオペレーティ
ングシステム４２とのインタフェースとなるＬ０インタ
フェース（レジスタインタフェース）と、オペレーティ
ングシステム４２とアプリケーションプログラム４３と
のインタフェースとなるＬ１インタフェース（サブルー
ティンコールインタフェース）といった境界で仕切られ
た作りとなっている。

【００３５】ここで、各デバイスヘの直接のアクセス制
御はオペレーティングシステムが行う。アプリケーショ
ンプログラム４３はコマンドベースの情報をＬ１インタ
フェースでオペレーティングシステムに渡すのみで、デ
バイスヘのアクセスは行わない。オペレーティングシス
テム４２の各デバイスドライバがサブルーティンとして
アプリケーションプログラムからコールされ、このと
き、アプリケーションプログラム４３は引数として動作
指示内容をオペレーティングシステム４２へ渡す。オペ
レーティングシステム４２はその指示内容に従いプログ
ラムの実行、ＩＯアクセス制御、結果のアプリケーショ
ンプログラム４３への戻しを行ってメインのアプリケー
ションプログラム４３のプログラムにリターンする。

【００３６】たとえば図示のようにアプリケーションプ
ログラム４３のタスクＡが実行中の際には、そのタスク
Ａが、Ｌ１インタフェースを使って、オペレーティング
システム４２の各種モジュールをサブルーティンコール
して実行させる。このとき、どのアプリケーションプロ
グラムのモジュールが動いているのかを知りたいので、
各モジュールにはそれらを識別するための識別番号が割
り当てられる。たとえば、図示の例では、タスクＡに、
識別番号としてタスク番号「０００００００１」が割り
当てられている。

【００３７】次に、タスクに割り当てられたタスク番号
がＰＣＩバスヘ伝達されるまでの手順について説明す
る。図８はプログラム走行履歴情報を外部へ導出する処
理の流れを示すフローチャートである。アプリケーショ
ンプログラムが起動すると、まず、アプリケーションプ
ログラムは、Ｌ１インタフェースを使ってメインメモリ
上の固定エリアにオペレーティングシステムの各プログ
ラム（たとえばディスクドライバやＬＡＮドライバや各
種システム運用上のプログラム）ごとの実行アプリケー
ションプログラム識別フィールドを設ける（ステップＳ
１）。また、アプリケーションプログラムは、アプリケ
ーションプログラムが属するモジュール（またはタス
ク）に固有の識別番号、ここではタスク番号を割り当て
る（ステップＳ２）。次に、アプリケーションプログラ
ムがオペレーティングシステムのドライバを起動する
際、すなわちタスクコールまたはサブルーティンコール
する際に、アプリケーションプログラムはメインメモリ
の固定エリアに設けられた実行アプリケーションプログ
ラム識別フィールドにタスク番号を格納する（ステップ
Ｓ３）。サブルーティンコールされたオペレーティング
システムは各プログラムごとの実行アプリケーションプ
ログラム識別フィールドをリードし、実行中のタスクの
タスク番号を得る（ステップＳ４）。次に、オペレーテ
ィングシステムのプログラムの中に存在する外部バス
（ここではＰＣＩバス）上の制御空間アクセス時に、オ
ペレーティングシステムは得られたタスク番号を内部プ
ロセッサアドレスビットフィールドの２３−１６ビット
のモニタフィールドに挿入する（ステップＳ５）。オペ
レーティングシステムはタスク番号を挿入したアドレス
でロード／ストア命令を実行する（ステップＳ６）。そ
の結果、そのタスク番号を含んだアドレスによるバスト
ランザクションが、内部プロセッサバスからバスブリッ
ジを通ってＰＣＩバスヘ伝達される。

【００３８】このＰＣＩバスに現れる制御空間アクセス
トランザクションにおけるアドレス情報をロジックアナ
ライザなどの測定器でモニタリングし、収集蓄積すれ
ば、プロセッサがどのようなアプリケーションプログラ
ムをどのような順番で実行していたかを把握することが
でき、それによって、ある問題の解析パターンが見えて
くるようになる。

【００３９】図９はソフトウェアの機能を示すブロック
図である。アプリケーションプログラム（ＡＰＬ）４３
はＬ１インタフェースによってオペレーティングシステ
ム４２に接続され、オペレーティングシステム４２はＬ
０インタフェースによってハードウェア／ファームウェ
ア４１に接続されている。アプリケーションプログラム
４３は、システム運用プログラム、呼処理制御プログラ
ム、課金制御プログラム、障害処理プログラムなどの交
換機用の各種プログラムを含んでいる。オペレーティン
グシステム４２は、その中心的な働きをする制御プログ
ラムであるカーネル、各種デバイスドライバ用のプログ
ラムなどを含んでいる。ハードウェア／ファームウェア
４１は、マイクロプロセッサ（ＭＰＵ）、ＲＯＭ(Read
Only Memory)、ＲＡＭ（Random Access Memory）、入出
力コントローラ（ＩＯＣ）（ＬＡＮＣ／ＳＰＣ）などか
らなる。アプリケーションプログラム４３からオペレー
ティングシステム４２に対しては、Ｌ１インタフェース
を介してサブルーティンコール（Ｃａｌｌ）が実行さ
れ、オペレーティングシステム４２からはＬ１インタフ
ェースを介してアプリケーションプログラム４３にリタ
ーン（Ｒｅｔ）が実行される。また、オペレーティング
システム４２はハードウェア／ファームウェア４１に対
しＬ０インタフェースを介して、オペレーティングシス
テムプログラム走行、ＩＯＣ（ＬＡＮＣ／ＳＰＣ）レジ
スタアクセス、ＩＯＣ・メインメモリ（ＭＭ）間データ
転送などが実行される。

【００４０】アプリケーションプログラム４３として
は、アプリケーションプログラム実行部４３ａ、Ｌ１イ
ンタフェース起動条件設定部４３ｂと、Ｌ１インタフェ
ース結果確認部４３ｃの各機能からなっており、オペレ
ーティングシステム４２としては、Ｌ１インタフェース
起動条件確認部４２ａと、ドライバ実行部４２ｂと、Ｌ
１インタフェース実行結果通知部４２ｃの各機能からな
っている。

【００４１】アプリケーションプログラム４３におい
て、アプリケーションプログラム実行部４３ａから起動
要求があると、Ｌ１インタフェース起動条件設定部４３
ｂは、オペレーティングシステムの各プログラムをサブ
ルーティンコールするに当たり、具体的な制御内容（た
とえばデータ転送であれば、転送容量、転送方向、転送
アドレスなどの情報)をメインメモリの固定エリアにセ
ーブし、コール命令を実行する。オペレーティングシス
テム４２では、Ｌ１インタフェース起動条件確認部４２
ａが、コールされた時点でメインメモリ上の制御内容の
正常性を確認し、正常ならば、各動作実行をドライバ実
行部４２ｂへ要求し、制御内容が異状なら、Ｌ１インタ
フェース実行結果通知部４２ｃへエラー通知要求を行
う。ドライバ実行部４２ｂは要求された動作を実行し、
実行結果の通知をＬ１インタフェース実行結果通知部４
２ｃに要求する。Ｌ１インタフェース実行結果通知部４
２ｃは、オペレーティングシステムの実行結果をメイン
メモリ上の固定エリア（Ｌ１インタフェース起動条件設
定部４３ｂで設定するのとは別のエリア）にセーブし、
アプリケーションプログラム４３へ戻るためにリターン
命令を実行する。Ｌ１インタフェース実行結果通知部４
２ｃでは、Ｌ１インタフェースへの起動結果を確認し、
アプリケーションプログラム実行部４３ａへ結果通知を
行う。

【００４２】なお、太枠で示したアプリケーションプロ
グラム４３のＬ１インタフェース起動条件設定部４３ｂ
およびオペレーティングシステム４２のＬ１インタフェ
ース起動条件確認部４２ａが従来の機能にタスク番号の
処理機能が付加されている部分であり、以下、その処理
を含むＬ１インタフェースの詳細な処理について説明す
る。

【００４３】図１０はＬ１インタフェースの制御の流れ
を示すフローチャートである。アプリケーションプログ
ラム実行部から起動要求があると、まず、データ転送が
あるかどうかが判断される（ステップＳ１１）。データ
転送がある場合には、転送容量／転送方向／転送アドレ
スをメインメモリ上の固定エリアにセーブし（ステップ
Ｓ１２）、実行タスク番号をメインメモリ上の固定エリ
アにセーブする（ステップＳ１３）。データ転送がない
場合あるいはステップＳ１３における実行タスク番号の
セーブが終了すると、オペレーティングシステムに対し
てコール命令が実行される（ステップＳ１４）。

【００４４】オペレーティングシステムでは、まず、メ
インメモリのセーブエリアをリードしてオペレーティン
グシステム起動情報を確認するとともに、タスク番号も
メインメモリからリードする（ステップＳ１５）。次
に、データの正常性の確認が行われる（ステップＳ１
６）。データが正常ならば、オペレーティングシステム
実行部へ実行要求が出され、オペレーティングシステム
実行部がその要求を実行する（ステップＳ１７）。すな
わち、各種ハードウェアをレジスタアクセスで制御しつ
つオペレーティングシステムプログラムを走行させる
が、ＬＡＮコントローラ２８およびＳＣＳＩバスコント
ローラ２７などのレジスタアクセス時にアプリケーショ
ンプログラムからメインメモリ経由で渡された実行タス
ク番号をレジスタアドレスに挿入してロード／ストア命
令を実行する。次に、終了情報をメインメモリ上の固定
エリアにセーブし（ステップＳ１８）、リターン命令を
実行する（ステップＳ１９）。一方、ステップＳ１６の
判断において、データの正常性が確認されなければ、エ
ラー情報をメインメモリ上の固定エリアにセーブし（ス
テップＳ２０）、リターン命令を実行する（ステップＳ
２１）。

【００４５】アプリケーションプログラムでは、コール
命令を実行した後、オペレーティングシステムからの応
答を監視している（ステップＳ２２）。オペレーティン
グシステムから応答があると、メインメモリ上の実行結
果セーブエリアをリードし（ステップＳ２３）、実行結
果をチェックする（ステップＳ２４）。ここで、実行結
果にエラー情報があるかどうかが判断され（ステップＳ
２５）、エラー情報があれば、障害処理アプリケーショ
ンプログラムへエントリ移行を行い（ステップＳ２
６）、エラー情報がなければ、アプリケーションプログ
ラム処理を継続する（ステップＳ２７）。

【００４６】なお、このフローチャートにおいて、太枠
で示したステップが本発明によって変更された部分であ
る。すなわち、アプリケーションプログラムでは、実行
タスク番号をセーブしておくためのステップＳ１３が追
加され、オペレーティングシステムでは、ステップＳ１
５およびＳ１７がタスク番号を処理するよう変更されて
いる。

【００４７】次に、本発明の第２の実施の形態について
説明する。ここでは、アプリケーションプログラムを実
行するたびにそのアプリケーションプログラムを識別す
る番号をメインメモリに保持しておき、後で、保持され
た識別番号をメインメモリから採取することによって、
実行アプリケーションプログラムのどのモジュールが動
いていたかを観測しようとするものである。

【００４８】図１１は第２の実施の形態におけるソフト
ウェアの機能を示すブロック図である。図１１におい
て、図９に示した要素と同じ要素は同じ符号を付してあ
る。本実施の形態では、オペレーティングシステム４
２、Ｌ１インタフェース起動条件確認部４２ａからサブ
ルーティンコールされるアプリケーションプログラム
(ＡＰＬ)識別番号格納プログラム４２ｄを新たに備えて
いる。このアプリケーションプログラム識別番号格納プ
ログラム４２ｄは、オペレーティングシステム４２にお
ける本来のプログラム実行に先立って起動され、アプリ
ケーションプログラム識別番号をメインメモリに保持し
ておく機能を有する。

【００４９】オペレーティングシステム４２において、
アプリケーションプログラム４３からコールされると、
Ｌ１インタフェース起動条件確認部４２ａは、その時点
でメインメモリ上の制御内容の正常性を確認し、正常な
らば、まず、アプリケーションプログラム識別番号格納
プログラム４２ｄをコールして、アプリケーションプロ
グラム識別番号をメインメモリ上に格納させる。アプリ
ケーションプログラム識別番号格納プログラム４２ｄか
らリターンされると、その後、Ｌ１インタフェース起動
条件確認部４２ａは最初に起動されるはずであった動作
実行をドライバ実行部４２ｂへ要求する。Ｌ１インタフ
ェース起動条件確認部４２ａは、また、制御内容が異状
なら、Ｌ１インタフェース実行結果通知部４２ｃへエラ
ー通知要求を行う。

【００５０】次に、アプリケーションプログラム４３と
オペレーティングシステム４２との間のＬ１インタフェ
ースの詳細な処理について説明する。図１２はＬ１イン
タフェースの制御の流れを示すフローチャート、図１３
はアプリケーションプログラム識別番号格納プログラム
の処理の流れを示すフローチャートである。アプリケー
ションプログラム実行部から起動要求があると、まず、
データ転送があるかどうかが判断される（ステップＳ３
１）。データ転送がある場合には、転送容量／転送方向
／転送アドレスをメインメモリ上の固定エリアにセーブ
する（ステップＳ３２）。次に、アプリケーションプロ
グラムはＬ１インタフェースを使ってメインメモリ上の
固定エリアにオペレーティングシステムの各プログラム
(たとえばＬＡＮドライバ、ディスクドライバ、あるい
は各種運用上のプログラム)ごとの実行アプリケーショ
ンプログラム識別フィールドを設定し、そこに実行アプ
リケーションプログラムを識別する固有のアプリケーシ
ョンプログラム識別番号（たとえば各モジュールに割り
当てられたタスク番号）をセーブする（ステップＳ３
３）。データ転送がない場合あるいはステップＳ３３に
おけるアプリケーションプログラム識別番号のセーブが
終了すると、オペレーティングシステムに対してコール
命令が実行される（ステップＳ３４）。

【００５１】オペレーティングシステムでは、まず、メ
インメモリのセーブエリアをリードしてオペレーティン
グシステム起動情報を確認して（ステップＳ３５）、ア
プリケーションプログラム識別番号格納プログラムをコ
ールし、アプリケーションプログラム識別番号格納プロ
グラムによるアプリケーションプログラム識別番号格納
処理が行われる（ステップＳ３６）。

【００５２】このアプリケーションプログラム識別番号
格納処理では、図１３に示したように、まず、メインメ
モリ上の次格納アドレスポインタ領域をリードしてアプ
リケーションプログラム識別番号を保持しておくための
格納アドレスを得る（ステップＳ５１）。次に、メイン
メモリ上のアプリケーションプログラム識別番号が格納
されたエリアをリードしてアプリケーションプログラム
識別番号を取得する（ステップＳ５２）。そして、取得
したアプリケーションプログラム識別番号をステップＳ
５１で得られた格納アドレスのアプリケーションプログ
ラム識別番号格納領域に格納する（ステップＳ５３）。
さらに、アプリケーションプログラム識別番号格納プロ
グラムは、アプリケーションプログラム識別番号の取得
の際にプロセッサ内部のタイマをリードすることによっ
て得られたタイムスタンプを、先にアプリケーションプ
ログラム識別番号を格納したアプリケーションプログラ
ム識別番号格納領域に対応するタイムスタンプ格納領域
に格納する（ステップＳ５４）。次に、次格納アドレス
ポインタ領域のポインタをそのタイムスタンプ格納領域
の次のアドレスに更新して（ステップＳ５５）、このア
プリケーションプログラム識別番号格納プログラムを抜
ける。

【００５３】次に、オペレーティングシステムの処理で
は、データの正常性の確認が行われる（ステップＳ３
７）。データが正常ならば、オペレーティングシステム
実行部へ実行要求が出され、オペレーティングシステム
実行部がその要求を実行する（ステップＳ３８）。次
に、終了情報をメインメモリ上の固定エリアにセーブし
（ステップＳ３９）、リターン命令を実行する（ステッ
プＳ４０）。一方、ステップＳ３７の判断において、デ
ータの正常性が確認されなければ、エラー情報をメイン
メモリ上の固定エリアにセーブし（ステップＳ４１）、
リターン命令を実行する（ステップＳ４２）。

【００５４】アプリケーションプログラムでは、ステッ
プＳ３４にてコール命令を実行した後、オペレーティン
グシステムからの応答を監視している（ステップＳ４
３）。オペレーティングシステムから応答があると、メ
インメモリ上の実行結果セーブエリアをリードし（ステ
ップＳ４４）、実行結果をチェックする（ステップＳ４
５）。ここで、実行結果にエラー情報があるかどうかが
判断される（ステップＳ４６）。実行結果にエラー情報
があれば、障害処理アプリケーションプログラムへエン
トリ移行を行い（ステップＳ４７）、エラー情報がなけ
れば、アプリケーションプログラム処理を継続する（ス
テップＳ４８）。

【００５５】図１４はメインメモリ上のマッピング例を
示す図である。メインメモリ上において、Ａ番地以降は
アプリケーションプログラム識別番号格納プログラムが
実行中のアプリケーションプログラムのアプリケーショ
ンプログラム識別番号を保持しておく領域であり、この
領域はあらかじめオペレーティングシステムによって割
り当てられている。Ｂ番地以降の領域は、アプリケーシ
ョンプログラムがＬ１インタフェースを使ってオペレー
ティングシステムの各プログラムごとに設定される実行
アプリケーションプログラム識別番号フィールドになっ
ている。アプリケーションプログラムはそれぞれのモジ
ュールに固有の識別番号を割り当てており、あるモジュ
ールがオペレーティングシステムのあるドライバを起動
する際、すなわちタスクコールやサブルーティンコール
する際に、そのアプリケーションプログラム識別番号を
実行アプリケーションプログラム識別番号フィールドに
格納する。

【００５６】図示の例では、あるアプリケーションプロ
グラムが起動し、Ｂ番地のアドレスに実行中のアプリケ
ーションプログラムによるアプリケーションプログラム
識別番号が格納されているとする。

【００５７】起動されたオペレーティングシステムは、
その処理の先頭で、アプリケーションプログラム識別番
号格納プログラム（サブルーティン）をコールする。コ
ールされたアプリケーションプログラム識別番号格納プ
ログラムは、メインメモリ上のＡ番地にある次格納アド
レスポインタの領域をリードする（矢印４４）。最初
は、このポインタはＡ＋４番地を指している。次に、ア
プリケーションプログラム識別番号格納プログラムは、
メインメモリ上のＢ番地のアドレスにある実行中のアプ
リケーションプログラムによるアプリケーションプログ
ラム識別番号格納領域から起動されたアプリケーション
プログラムのアプリケーションプログラム識別番号をロ
ードして（矢印４５）、ポインタが指し示すＡ＋４番地
のアプリケーションプログラム識別番号格納領域にスト
アする（矢印４６）。アプリケーションプログラム識別
番号格納プログラムは、さらに、Ａ＋８番地の領域に、
Ａ＋４番地の格納情報を収集した時刻としてプロセッサ
内のカレンダタイマからロードしたタイムスタンプをス
トアする（矢印４７）。タイムスタンプは、年月日／時
分秒を表す値であり、１／１０００秒まで計測できるプ
ロセッサ内のカレンダタイマからリードされる。アプリ
ケーションプログラム識別番号格納プログラムは、次に
格納する領域のアドレス（たとえばＡ＋１２番地）を次
格納アドレスポインタの領域に保持してリターンし、本
来のオペレーティングシステムの処理に入る。

【００５８】このように、Ｌ１インタフェースでアプリ
ケーションプログラムからオペレーティングシステムに
起動がかかるたびにその実行されたアプリケーションプ
ログラムの識別番号と実行時刻であるタイムスタンプと
をメインメモリ上にあらかじめ割り当てられた空間の若
番地から昇順に格納していくことにより、アプリケーシ
ョンプログラムの起動履歴情報が蓄積される。その後、
その情報が格納された領域をリードすることにより、ア
プリケーションプログラムのどのモジュールが動いてい
たかを確認することができる。

【００５９】このようにして蓄積した情報は、ソフトウ
ェアによってメインメモリからリードして表示させるこ
とができる。次に、その識別番号およびタイムスタンプ
の表示に関して述べる。

【００６０】実際に採取されるのはバイナリのデータで
あり、単純にこれらのデータの羅列をモニタしてもわか
りづらい。また、解析もしにくい。そこで、このデータ
を加工し表示するプログラムを準備することで見やす
く、解析もし易くなる。具体的には、このプログラム中
にアプリケーションプログラムとアプリケーションプロ
グラム識別番号との対応テーブルを持たせ、格納したバ
イナリ情報（アプリケーションプログラム識別番号）を
アプリケーションプログラムの固有名称に変換して表示
させる。これによりいちいち設計者が変換をかけながら
解析する手間を省くことができる。また、履歴として採
取されたアプリケーションプログラムの種別のみ表示さ
せる機能を持たせればイリーガルなアプリケーションプ
ログラムの存在を即時に発見可能となる。

【００６１】次に、ソフトウェアの走行履歴をモニタす
る別の方法について説明する。図１５は第３の実施の形
態におけるモニタ方法を説明する図である。図１５にお
いて、図２に示した要素と同じ要素は同じ符号を付して
ある。一般に入出力装置とメインメモリ間でのデータ転
送を行わせる場合、入出力装置がメインメモリ上の固定
エリア（そのデバイス固有の制御情報格納エリア）に転
送指示フラグがプログラムによって立てられているか否
かを周期的にハードＤＭＡ（Direct Memory Access）で
監視し、フラグが立っているのを入出力装置が検出した
場合にデータ転送を開始する。そのフラグ情報に、前述
の「実行ＡＰＬ識別番号（タスク番号）」を追加するこ
とにより、入出力装置からメインメモリへの転送指示フ
ラグリードサイクルを測定器で同様に監視することがで
き、より細かい実行プログラムトレースが可能となる。

【００６２】すなわち、まず、オペレーティングシステ
ムは初期設定動作を行うことにより、マイクロプロセッ
サ２１からＳＣＳＩバスコントローラ２７、ＬＡＮコン
トローラ２８に対して周期監視動作開始が指示される
（矢印５１）。これにより、ＳＣＳＩバスコントローラ
２７、ＬＡＮコントローラ２８は周期監視動作を開始す
る。

【００６３】次に、オペレーティングシステムにより、
メインメモリ２４の転送エリアに転送データが格納さ
れ、フラグ格納エリア２４ａには転送情報（転送容量／
転送方向）とフラグビットとが格納される（矢印５
２）。その後は、周期監視動作の処理が終わるまで、オ
ペレーティングシステムは周期監視アクセスを待機して
いる。

【００６４】次に、周期監視動作を開始したＳＣＳＩバ
スコントローラ２７またはＬＡＮコントローラ２８は、
データ転送起動状態監視のために周期的にメインメモリ
２４のフラグ格納エリア２４ａをリードしに行く（矢印
５３）。この周期監視でフラグビットが検出されると、
ここでＳＣＳＩバスコントローラ２７またはＬＡＮコン
トローラ２８は起動され、フラグ格納エリア２４ａのデ
ータとともにその転送情報とフラグビットとからメイン
メモリ２４上の転送データをＤＭＡで自デバイスへ転送
させ、自デバイスのデータをメインメモリ２４へ転送す
る。

【００６５】このように、デバイスが周期的にメインメ
モリ上に格納されたフラグビットを監視し、フラグビッ
トがある値を示している場合にそのデバイスが自律で起
動するような起動方法を採っている。ここで、周期的に
リードされるフラグ格納エリア２４ａは全ビットを使っ
ているわけではなく、未使用のビットフィールドが存在
している。その空いているビットフィールドに、設定し
に行ったタスクの番号を入れておき、ＳＣＳＩバスコン
トローラ２７またはＬＡＮコントローラ２８がフラグ格
納エリア２４ａをリードし、リードされたフラグビット
フィールドに含まれるタスク番号を測定器がモニタする
ことにする。

【００６６】図１６はメインメモリ上のフラグ格納エリ
アの例を示す図である。デバイスを起動するに当たっ
て、フラグエリアデータ（ＦＬＧ）、転送情報、転送デ
ータなどをメモリに設定し、後はＳＣＳＩバスコントロ
ーラ２７またはＬＡＮコントローラ２８から周期的に監
視されるのを待つ。監視は、フラグエリアデータのアド
レスＡを周期的に、たとえば１ミリ秒〜数十マイクロ秒
ごとにリードする。このリードの際のフラグエリアデー
タは、図３に示したリードタイミングのデータフィール
ド「ＤＡＴＡ」に保持される。このリードされたデータ
が測定器によってモニタされる。次に、リードしたＳＣ
ＳＩバスコントローラ２７またはＬＡＮコントローラ２
８は、フラグエリアデータの中のフラグビットをチェッ
クする。このアドレスＡをのリードの際に、同時に、転
送情報もリードしており、フラグビットに「１」が立っ
ていることを検出した場合には、その転送情報をもと
に、転送データを自デバイスまでＤＭＡで転送する。ま
たは、自デバイスから、転送情報で指示されたメインメ
モリ上のエリアへデータを転送する。

【００６７】図１７はメインメモリ上のフラグ格納エリ
アのビットフィールドの例を示す図である。フラグ格納
エリアは３２ビットからなり、２３−１ビットのフィー
ルドに転送容量／転送方向が割り当てられ、００ビット
のフィールドにフラグビットが割り当てられ、３１−２
４ビットのフィールドは未使用のフィールドであって、
ここにタスク番号を割り当てるためのモニタフィールド
としている。このように、ＩＯデバイスがフラグリード
時、すなわちＩＯデバイスからメモリヘのデータ転送起
動状態監視のためのリード時には、図３のデータフィー
ルド「ＤＡＴＡ」に図１７に示すビットフィールドが現
れるので、その中のモニタフィールド（ビット３１−２
４）にプログラムの識別番号を挿入することになる。

【００６８】このように、第１の実施の形態の場合のよ
うなアドレスサイクル上の識別フィールドを利用するだ
けではなく、このようなデバイスの周期監視によるリー
ドデータを利用する方法も併用することにより、ＰＣＩ
バス上に実行ＡＰＬ識別番号が出現する頻度が増え、結
果的にトレース情報の確度を上げることができる。

【００６９】また、上記のプロセッサシステムが有すべ
き機能の処理内容は、コンピュータで読み取り可能な記
録媒体に記録されたプログラムに記述させておくことが
できる。このプログラムをコンピュータで実行すること
により、上記処理がコンピュータで実現できる。コンピ
ュータで読み取り可能な記録媒体としては、磁気記録装
置や半導体メモリなどがある。市場に流通させる場合に
は、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）
やＭＯディスクなどの可搬型記録媒体にプログラムを格
納して流通させたり、ネットワークを介して接続された
コンピュータの記憶装置に格納しておき、ネットワーク
を通じて他のコンピュータに転送することもできる。コ
ンピュータで実行する際には、コンピュータ内のハード
ディスク装置などにプログラムを格納しておき、メイン
メモリにロードして実行する。

【００７０】

【発明の効果】以上説明したように本発明では、２階層
構成の汎用的なプロセッサシステムの１次側バスで走行
しているプログラムの履歴情報を２次バスに導き出すよ
うに構成した。このため、１次側へのハード的な付加測
定回路などを設置することなく２次バス側で１次側のプ
ログラムの走行状態が観測可能となる。

【００７１】ハード的な付加測定回路などの設置が必要
なく、すべてアプリケーションおよびオペレーティング
システムのレベルで２次側へのプログラム履歴情報の導
出が可能であることから、汎用高性能プロセッサモジュ
ールを採用したすべてのプロセッサシステムのデバッグ
に適用することができる。

【００７２】また、プログラムの走行履歴をメモリ上で
観測可能とすることによって、ハード的な採取方法と異
なり大量のトレースが採取可能となる。さらに、ＩＯデ
バイスがデータ転送起動状態監視のためにメインメモリ
へリードするデータの中にも同様にモジュール（または
タスク）番号を挿入することによって、１次側へのハー
ド的な付加測定回路などを設置することなく２次バス側
で１次側のプログラムの走行状態が観測可能となる。

【図面の簡単な説明】

【図１】本発明によるソフトウェア走行履歴モニタ方法
の原理説明図である。

【図２】プロセッサシステムへの測定器の設置例を示す
図である。

【図３】ＰＣＩバスのリードサイクル／ライトサイクル
についてのタイムチャートを示す図である。

【図４】アドレス情報のビットフィールドを示す図であ
って、（Ａ）は内部プロセッサバスアドレスビットフィ
ールドを示し、（Ｂ）はＰＣＩバスアドレスビットフィ
ールドを示している。

【図５】プロセッサシステムのアドレスマッピングの例
を示す図である。

【図６】モニタの概要を示す図である。

【図７】ソフトウェアの概念的な構成を示す図である。

【図８】プログラム走行履歴情報を外部へ導出する処理
の流れを示すフローチャートである。

【図９】ソフトウェアの機能を示すブロック図である。

【図１０】Ｌ１インタフェースの制御の流れを示すフロ
ーチャートである。

【図１１】第２の実施の形態におけるソフトウェアの機
能を示すブロック図である。

【図１２】Ｌ１インタフェースの制御の流れを示すフロ
ーチャートである。

【図１３】アプリケーションプログラム識別番号格納プ
ログラムの処理の流れを示すフローチャートである。

【図１４】メインメモリ上のマッピング例を示す図であ
る。

【図１５】第３の実施の形態におけるモニタ方法を説明
する図である。

【図１６】メインメモリ上のフラグ格納エリアの例を示
す図である。

【図１７】メインメモリ上のフラグ格納エリアのビット
フィールドの例を示す図である。

【図１８】プロセッサシステムの構成例を示す図であ
る。

【図１９】ハードウェアによるソフトウェアの走行履歴
確認の一例を示す図である。

【符号の説明】１０プロセッサシステム１１マイクロプロセッサ１２メインメモリ１３高速バス１４バスブリッジ１５低速バス１６入出力デバイス１７アプリケーションプログラム１８オペレーティングシステム１９測定器２１マイクロプロセッサ２２システムバスコントローラ２３クロスバスイッチ２４メインメモリ２４ａフラグ格納エリア２５バスブリッジ２６ＰＣＩバス２７ＳＣＳＩバスコントローラ２７ａハードディスク２７ｂＭＯディスクドライブ２８ＬＡＮコントローラ２８ａワークステーション３０測定器４１ハードウェア／ファームウェア４２オペレーティングシステム４３アプリケーションプログラム

Claims

【特許請求の範囲】

【請求項１】複数階層のバス構成を有するプロセッサ
システム上にて走行するソフトウェアの走行履歴をモニ
タするソフトウェア走行履歴モニタ方法において、最も下位側のバス上に発生する入出力デバイスヘのアク
セストランザクションのアドレス情報フィールドに走行
中のプログラムを識別するプログラム識別情報を持た
せ、前記最も下位側のバスにおいて前記アドレス情報フィー
ルド内の前記プログラム識別情報をモニタする、ことを特徴とするソフトウェア走行履歴モニタ方法。
【請求項２】前記アドレス情報フィールドにプログラ
ム識別情報を持たせるステップは、プログラムの走行の
際に前記プログラム識別情報をメインメモリの所定のエ
リアにセーブし、前記入出力デバイスヘのアクセス時に
前記メインメモリの所定のエリアにセーブされたプログ
ラム識別情報を前記アドレス情報フィールドの空きフィ
ールドに挿入するステップを有することを特徴とする請
求項１記載のソフトウェア走行履歴モニタ方法。
【請求項３】前記アドレス情報フィールドにプログラ
ム識別情報を持たせるステップは、アプリケーションプ
ログラムの起動の際に前記メインメモリに対して所定の
エリアの割り付けを行い、前記アプリケーションプログ
ラムがオペレーティングシステムをコールする際に前記
メインメモリの所定のエリアに前記プログラム識別情報
をセーブし、前記アプリケーションプログラムからコー
ル命令を受けたオペレーティングシステムが前記メイン
メモリの所定のエリアから前記プログラム識別情報をリ
ードし、前記プログラム識別情報を前記アドレス情報フ
ィールドの空きフィールドに挿入して前記入出力デバイ
スヘアクセスすることを特徴とする請求項１記載のソフ
トウェア走行履歴モニタ方法。
【請求項４】前記プログラム識別情報は、走行中のプ
ログラムが属するモジュール番号または実行タスク番号
とすることを特徴とする請求項１記載のソフトウェア走
行履歴モニタ方法。
【請求項５】複数階層のバス構成を有するプロセッサ
システム上にて走行するソフトウェアの走行履歴をモニ
タするソフトウェア走行履歴モニタ方法において、アプリケーションプログラムからオペレーティングシス
テムへのサブルーティンコールを契機としてその要求元
アプリケーションプログラムの固有識別番号をメインメ
モリ上に格納し、前記サブルーティンコールの実行タイムスタンプを前記
メインメモリ上に格納し、前記メインメモリ上に格納された前記固有識別番号およ
び実行タイムスタンプをモニタする、ことを特徴とするソフトウェア走行履歴モニタ方法。
【請求項６】前記固有識別番号を格納するステップ
は、アプリケーションプログラムの起動の際にメインメ
モリに対して第１の所定のエリアの割り付けを行い、前
記アプリケーションプログラムがオペレーティングシス
テムをコールする際に前記メインメモリの第１の所定の
エリアにアプリケーションプログラムの固有識別番号を
格納し、前記アプリケーションプログラムからコール命
令を受けたオペレーティングシステムが前記メインメモ
リの第１の所定のエリアから前記固有識別番号をリード
し、前記オペレーティングシステムによって割り付けら
れた前記メインメモリの第２のエリアにリードされた前
記固有識別番号を格納していくステップを有することを
特徴とする請求項５記載のソフトウェア走行履歴モニタ
方法。
【請求項７】複数階層のバス構成を有するプロセッサ
システム上にて走行するソフトウェアの走行履歴をモニ
タするソフトウェア走行履歴モニタ方法において、最も下位側のバス上に発生する入出力デバイスからメイ
ンメモリヘのデータ転送起動状態監視のためのリードト
ランザクションのデータフィールドに走行中のプログラ
ムを識別するプログラム識別情報を持たせ、前記最も下位側のバスにおいて前記データフィールド内
の前記プログラム識別情報をモニタする、ことを特徴と
するソフトウェア走行履歴モニタ方法。
【請求項８】前記データフィールドにプログラム識別
情報を持たせるステップは、周期監視動作の開始が指示
された入出力デバイスに対応するメインメモリのフラグ
エリアに走行しようとするプログラムを識別する前記プ
ログラム識別情報を挿入し、前記入出力デバイスによる
前記メインメモリのフラグエリアの周期的リードを待機
するステップを有することを特徴とする請求項７記載の
ソフトウェア走行履歴モニタ方法。
【請求項９】アプリケーションプログラムが起動の際
にメインメモリに対して所定のエリアの割り付けを行う
メモリ割り付け手段と、前記アプリケーションプログラ
ムがオペレーティングシステムをコールする際に前記メ
インメモリの所定のエリアに走行中のプログラムを識別
するプログラム識別情報を格納する格納手段とを有する
ソフトウェア走行履歴情報設定プログラムを記録したコ
ンピュータ読み取り可能な記録媒体。