JP2007041887A - デバッグ装置、そのメモリアクセス方法およびメモリアクセス方法を実現するプログラム - Google Patents

Abstract

【課題】 初期設定付メモリが初期化されメモリアクセス不可状態になってしまったときでも、ユーザーの負担無くブレーク機能を実現できるデバッグ装置を提供することを目的とする。
【解決手段】 初期設定が必要なメモリに対するソフトウェアブレークを設定する際、該メモリの状態がアクセス不可の場合、一旦アクセス要求として管理し、メモリの初期設定が行われた時点でソフトウェアブレークの設定処理（メモリアクセス処理）を実行する。これにより、デバッグ装置内部の処理を意識した煩わしい操作をすることなくデバッグ作業を行うことができ、ユーザーの負担を軽減できる。
【選択図】 図９

Description

本発明は、組み込みシステムのソフトウェア開発におけるデバッグ装置およびメモリアクセス方法において、特に使用前に初期設定が必要なメモリ領域で実行するソフトウェア（ソフトウェアブレークの設定方法）に関するものである。

従来、ソフトウェアブレークは、プログラムを停止させたいアドレスにあるプログラム命令を、プログラム制御を変更するための命令、例えば割込みを発生させる命令（トラップ命令）に、一時的に置き換えることで実現していた。トラップ命令に置き換えるとは、具体的にはメモリの値を書き換えることを意味している。

命令を置き換えるタイミングは、デバッグ装置に制御がある状態（ブレーク状態）からユーザプログラムに制御が移る（ユーザプログラム実行状態に移行する）ときであり、その時点で設定されている全てのソフトウェアブレークポイントのアドレスにあるプログラム命令を所定の命令に書き換えていた。（非特許文献１参照）。
Jonathan B.Rosenberg著／吉川 邦夫訳「デバッグ装置の理論と実装」アスキー出版、ISBN 4-7561-1745-7, 1998/02

組み込みシステムのソフトウェア開発におけるデバッグ方法として、ブレーク機能は有用である。その中でもインサーキットエミュレータ（ＩＣＥ）やオンチップデバッグ機能といったハード資源が必要となるハードウェアブレークに比べて、ソフトウェアブレークは、回数など複雑な条件指定はできないし、命令ブレークのみであるなど、簡便な機能ではあるが、特殊なブレーク命令を書き込み実行させるだけで特別なハード資源を必要とせずブレーク本数をある意味無限数にできるので、非常に有効な機能となっている。

しかし、この従来方法ではブレークポイントを設定できるのは書き換え可能なＲＡＭメモリに展開されたプログラムに限られてしまい、書き換えできないＲＯＭメモリにソフトウェアブレークを設定することは物理的にできない。また、ＳＤＲＡＭメモリなど所定の設定（制御）をしないとメモリアクセスができないといった種類のメモリの場合に、ＲＯＭメモリと同様にブレーク設定（メモリ設定）ができない問題があった。

以下に詳細を説明する。図１１に従来のソフトウェアブレーク設定に関する、ユーザ１３０、デバッグ装置（デバッガ）１２０、ユーザプログラム処理１１０、初期設定付きメモリ１００の状態の時系列の関係を示す。

まずデバッグ装置１２０が起動されると、ユーザ１３０からのコマンド待ち状態になる（ステップ１２１）。
ユーザ１３０は、まずデバッグ対象となるユーザプログラム１１０をメモリ上にロードする（ステップ１３１）。ここでロードするメモリは初期設定付メモリ１００とは違い、いずれの状態でも基本的に読み書き可能なメモリとする。

その後、ユーザ１３０はＧｏ実行すると（ステップ１３２）、デバッグ装置１２０で実行処理が行われ（ステップ１２２）、ユーザプログラム１１０が実行される（ステップ１１１）。なお、この時点１０１では、初期設定付きメモリ１００に対して初期設定がされておらず、ソフトウェアブレーク設定のための処理は実行できない。

ユーザプログラム１１０が実行されると、まずスタートアップ処理が行われる（ステップ１１２）。ここではスタックポインタやＩ／Ｏレジスタの初期設定、初期データやプログラムの転送といった処理など、ユーザプログラムの動作に必要な前処理がされる。本発明で対象としている初期設定が必要なメモリ１００なども、この時点で使えるように適宜設定をしておく。この時点１０２で、初期設定付メモリ１００は、ユーザプログラム１１０からもデバッグ装置１２０からも読み書き可能な状態となっており、その初期設定付メモリ１００上で動作するプログラムなどはこの状態に移行後に転送処理される。

ユーザプログラム１１０はスタートアップ処理（ステップ１１２）後、初期設定付メモリ１００に転送されたプログラム処理が実行される。
ユーザプログラム１１０の実行中、ユーザ１３０からの強制停止を含めて何らかの要因によりマイコンにブレーク割込みが発生すると、デバッグ装置１２０の割込み処理である停止後の処理が実行され（ステップ１２３）、デバッグ装置１２０およびユーザ１３０に制御が移ってくる。

そこでユーザ１３０はデバッグ装置１２０を使って、ユーザプログラム１１０の変数やメモリの値を見たり、トレース結果を確認したりとデバッグ作業１３３を行う。このデバッグ作業１３３の中で、次のデバッグ作業のための前処理として、（ソフトウェア）ブレークを設定することになる。

このソフトウェアブレーク設定の後、Ｇｏ実行すると（ステップ１３４）、先に説明したプログラムロード（ステップ１３１）後のＧｏ実行（ステップ１３２）時と同様に、デバッグ装置１２０で実行処理が行われる（ステップ１２４）。但し、今回の実行処理（ステップ１２４）では、先に加えて、ソフトウェアブレーク設定のための処理が必要となる。具体的には、まず指定ブレークアドレスの命令コードを読み込み、保存した上でブレーク割込み用の命令コード・トラップ命令を所定のメモリに書き込む。この書き込むべきアドレスには、初期設定が必要なメモリが割り付けられたアドレス範囲も含んでいるものとする。この時点での初期設定付メモリ１００への読み書きは、先に説明したユーザプログラム１１０のスタートアップ処理（ステップ１１２）のメモリに対する初期設定を実施済みのため、問題無く行うことができる。このデバッグ装置１２０の実行処理（ステップ１２４）の後、ユーザプログラム１１０は再び実行状態となる（ステップ１１３）。

ユーザプログラムが先に設定したソフトウェアブレークなどによりブレーク割込みが発生した場合、デバッグ装置１２０の割込み処理である停止後の処理が実行され（ステップ１２５）、デバッグ装置１２０およびユーザ１３０に制御が戻ってくる。このデバッグ装置１２０の停止処理（ステップ１２５）は、先に説明した停止処理（ステップ１２３）に加えて、ソフトウェアブレーク設定に関する後処理が行われる。具体的には、デバッグ装置１２０の実行処理（ステップ１２４）でブレーク割込み用命令を書き込んだアドレスに保存・退避しておいた元の命令コードを書き戻す。基本的には、これらの処理が繰り返されることで、デバッグを進めていくことになる。

ここで問題となってくるのが、初期設定付メモリ１００の状態がアクセス不可状態のとき、デバッグ装置１２０の実行処理１２４のブレーク割込み用の命令コード書き換え、または停止処理１２５における退避した元命令の書き戻しが発生した場合に、アクセスできないといったことである。これらの処理は、ユーザ１３０から見えないデバッグ装置１２０の内部的な処理になり、ソフトウェアブレークを設定している以上は、基本的に回避することはできない。

メモリアクセス不可状態となるには、例えばシステムまたはマイコンにリセットが入った場合に周辺レジスタの設定、つまりメモリへのアクセスに関する設定が初期化されてしまう（設定が元に戻りアクセスできない状態になってしまう）といったケースが考えられる。

通常デバッグ装置１２０からもリセット入力が可能で、ユーザ１３０によるデバッグ１３５の中で、既にユーザプログラム１１０が暴走していた、またはデバッグ手順のミスなどといった場合にユーザプログラム１１０を元に戻して最初から実行する際にリセットを行う（ステップ１３６）ことが多い。ユーザ１３０からこのリセットが入力されると（ステップ１３６）、デバッグ装置１２０はリセット処理を行い（ステップ１２６）、その処理の結果としてユーザプログラム１１０のスタートプログラムカウンタＰＣが初期値（リセットＰＣ値）に戻り、かつ、初期設定付メモリ１００は初期化されメモリアクセス不可状態になってしまう（ステップ１０５）。この後に、ユーザがＧｏ実行すると（ステップ１３７）、同様にしてデバッグ装置１２０の実行処理が行われ（ステップ１２７）、この中ではソフトウェアブレーク設定のためのブレーク割込み用の命令が書き込まれる。このときに、初期設定付メモリの状態１００はユーザプログラム１１０がプログラムスタートして（ステップ１１１）から、スタートアップ処理１１２の中のメモリ初期設定を行う前の状態１０２と同じであり、ブレーク割込み用の命令の書き込み処理は失敗し、デバッグ装置１２０の実行処理（ステップ１２７）が失敗、Ｇｏ実行（ステップ１３７）ができない状態となってしまう。

こうした問題は、従来のインサーキットエミュレータ（ＩＣＥ）といった開発環境の場合は(常に書き込み可能な)エミュレーションメモリを有していることから問題なかったが、近年主流となっているオンチップデバッグではターゲットシステム上の実ＣＰＵ、実メモリなどを使うことから透過性の意味で利点があるものの、上述の問題を回避することができず制限を受けたままでデバッグ効率の面で大きな課題となる。

同様の問題は、ソフトウェアブレーク設定の基本的な処理である、メモリアクセス機能でも該当し、実際にメモリアクセスを行ってしまうと、一連の処理の中でメモリアクセスを失敗と判断するための待ち状態が発生するために時間的なロスが出るとともに、デバッグ効率が落ちてしまう。

そこで本発明は、初期設定付メモリが初期化されメモリアクセス不可状態になってしまったときでも、ユーザの負担無くブレーク機能を実現できるデバッグ装置およびメモリアクセス方法を提供することを目的としたものである。また本発明は、無駄なメモリアクセスを行わずエラーを起こさず時間的なロスを回避できるデバッグ装置およびメモリアクセス方法を提供することを目的としたものである。

前述した目的を達成するために、本発明のうち請求項１に記載のデバッグ装置は、初期設定を要するメモリ上で動作するプログラムのデバッグ装置であって、設定されたシステムのメモリ情報を管理するメモリ情報管理部と、メモリへのアクセスが可能かどうかをメモリ情報管理部から指示された検出方法により検出するメモリ初期設定検出部と、ユーザインターフェイスやデバッグ装置内部からの要求に応じてメモリへの読み書きを行うメモリアクセス部とを備え、メモリアクセスが要求された該メモリがアクセス不可状態であった場合にメモリアクセスをしないようにしたことを特徴とするものである。

上記構成によれば、アクセス要求のあったメモリの状態が初期設定されていないアクセス不可状態であった場合、実際のメモリへのアクセスを行わないことにより、メモリアクセスに伴う無駄なシーケンス中の待ち時間を省くことが可能となる。また、まだ初期設定されていない旨をユーザに通知することで、単なるメモリアクセスが失敗しただけでない付加的な情報を与えることが可能となり、その後の再度の無駄なメモリアクセスの要求を抑制することが可能となる。

また請求項２に記載の発明は、請求項１に記載の発明であって、メモリアクセスの要求時点でアクセスができない状態であったアクセス要求を管理するメモリアクセス管理部を備え、メモリアクセスが可能となった時点でメモリアクセス管理部にて管理されているアクセス要求を再度実行するようにしたことを特徴とするものである。

上記構成によれば、ユーザなどからアクセス要求があった際に、該メモリがアクセス不可状態であった場合でもメモリ状態がアクセス可能となった時点で再度そのアクセス要求が実施され、メモリの状態を特に意識することなくメモリへのアクセスを要求（つまりデバッグなどを操作）することができ、適切な時点で確実にメモリへのアクセスを行うことが可能となる。

また請求項３に記載の発明は、請求項２に記載の発明であって、メモリのアクセスを可能にするための設定情報を管理し、要求に応じて処理を行うメモリアクセス設定部とを備え、メモリアクセスの要求があった際に設定可能とするための設定情報(処理)を実行した上でメモリアクセスを行えるようにすることを特徴とするものである。

上記構成によれば、ユーザからアクセス要求があった時点でメモリアクセス不可な状態であった場合も、確実にデバッグ装置から直接該メモリの初期設定をすることで、メモリアクセスの要求時点で確実に実行することが可能となる。

また請求項４に記載の発明は、請求項１〜請求項３のいずれかに記載の発明であって、メモリの値を表示するメモリ表示ユーザーインターフェイス部を備え、メモリアクセスが可能かどうかの状態に応じてメモリ値の表示に抑制をかけることにより、無駄なアクセス要求をしないようにすることを特徴とするものである。

上記構成によれば、メモリの状態に応じてデバッグ装置などのメモリ表示ユーザーインターフェイス部のメモリ値の表示を変化させることにより、予めユーザーからのアクセス要求自体を抑制することができ、無駄なメモリアクセスに関する処理を無くすことが可能となる。

また請求項５に記載の発明は、請求項１〜請求項４のいずれかに記載の発明であって、ソフトウェアブレークの設定を管理するソフトウェアブレーク管理部を備え、ソフトウェアブレークの命令コードの読み書き処理では、アクセス不可なメモリへのソフトウェアブレークは設定せず、メモリがアクセス可能になった時点でソフトウェアブレークを設定し、プログラム停止時の元の命令の書き戻し処理では、前記読み書き処理を行ったソフトウェアブレークを書き戻すようにすることを特徴とするものである。

上記構成によれば、メモリアクセス機能を有したソフトウェアブレーク機能において、メモリアクセスが不可なとき、ソフトウェアブレークコードの書込みや元コードの読み込みといった無駄なメモリアクセスをなくすことができ、メモリアクセスが可能となった時点でソフトウェアブレークの実現に伴うメモリアクセスを行うことができる。

また請求項６，７に記載の発明は、請求項１〜請求項５のいずれかに記載の発明であって、メモリ初期設定検出部をそれぞれ命令実行アドレスイベント機能およびデータアクセスイベント機能とし、メモリアクセスを可能とする設定を行った直後の命令アドレスおよびメモリアクセス設定をするデータアドレス（アクセスデータ値などを含む）へのアクセスを検知して、メモリへの適切なアクセスの制御ができるようにすることを特徴とする。

また請求項８に記載の発明は、請求項１〜請求項５のいずれかに記載の発明であって、メモリ初期設定検出部を、ポーリングによる定期的な実際のメモリアクセス処理とし、定期的にメモリアクセス可状態をチェックして、メモリへの適切なアクセスの制御ができるようにすることを特徴とする。

また請求項９〜請求項１６に記載の発明はそれぞれ、上記請求項１〜請求項８に対応するメモリアクセス方法を特徴とする。
また請求項１７の発明は、請求項９〜請求項１６のいずれか１項に記載のメモリアクセス方法の少なくともひとつをコンピュータに実行させることを特徴とする。

本発明のデバッグ装置とメモリアクセス方法は、初期設定を要するメモリ上で動作するプログラムのデバッグにおいて、予めメモリの領域やメモリ種別を登録し、さらに現在のメモリの状態（アクセス可能かどうか）を管理することにより、メモリの状態に応じてユーザのデバッグ操作による要求に適切に対応することが可能となる、という効果を有している。

以下、本発明の実施の形態を、図面を参照しながら説明する。
［実施の形態１］
図１は、本発明の実施の形態１におけるデバッグ装置の構成図であり、メモリアクセス方法の実現のための構成を示している。

デバッグ装置には、メモリ情報管理部２０１、メモリ初期設定検出部２０２、メモリアクセス部２０３、メモリアクセス管理部２０４が備えられている。
メモリ情報管理部２０１は、ユーザなどによって登録されるデバッグ対象となるターゲットシステムのメモリ情報を管理する。図２はこのメモリ情報管理部２０１に登録・管理されているメモリ情報・管理テーブルの一例を示す。ここでは、ＩＤ３０１は複数のメモリ情報を管理するためのＩＤ、アドレス範囲３０２はターゲットシステム上でメモリが割り付けられている開始および終了アドレス値、メモリ種別３０３はマイコン内蔵のメモリや本発明の対象となるＳＤＲＡＭやフラッシュメモリといったメモリの種類、状態３０４は現在のメモリへのアクセス可／不可状態、初期設定検出方法３０５はメモリのアクセス可／不可状態の変化を検出するための手段をそれぞれあらわすものとする。

メモリ初期設定検出部２０２は、メモリ情報管理部２０１が管理しているメモリ情報内の初期設定検出方法３０５を用いて常時チェックする。メモリの初期設定検出方法としては、ユーザプログラムでメモリの初期設定をする処理よりも後に実行される処理のアドレスを監視する命令実行アドレスイベント、メモリの初期設定をする周辺Ｉ／Ｏレジスタへのアクセスをデータアドレスおよびデータ値を基に監視するデータアクセスイベント、メモリの初期設定を行う特殊な命令を監視する命令イベントといった検出イベント（条件イベント）を使った方法や、ある一定間隔で実際にそのメモリに対するアクセスが可能になったかどうかを確認するポーリング処理を使った方法がある。

メモリアクセス部２０３は、ユーザなどからの要求に応じて該メモリへのアクセスを行う。但し、実際にはメモリ情報管理部２０１の管理するメモリ情報・管理テーブル（図２）内のメモリアクセス可・不可状態に応じてメモリアクセスが可能な場合にのみ、メモリへのアクセスを行うことになる。

メモリアクセス管理部２０４は、ユーザなどからのメモリアクセス要求時に該メモリがアクセス不可状態であった要求を管理し、該メモリがアクセス可状態になった際に再度メモリアクセス部２０３にメモリアクセスを要求する。図３はこのメモリアクセス管理部２０４へ登録・管理されているメモリアクセス要求・管理テーブルの一例である。ここでは、ユーザなどからメモリアクセス部２０３へ行われたと同じメモリアクセス要求情報４０１、メモリアクセスが要求された該メモリ情報を示すＩＤ４０２をあらわしている。

以上のように構成された実施の形態１におけるメモリアクセス方法について、図１、２、３および図４のフローチャートを用いて説明する。尚、本発明はメモリアクセス要求があってから該メモリのアクセス可・不可状態に応じた処理（メモリアクセス実行、またはアクセス要求登録）がされるまでの第１ステップ（ステップ５０１〜ステップ５０４，ステップ５１０，５１１）と、各メモリのアクセス可・不可状態を監視中にメモリの初期設定が行われてから該メモリに対するメモリアクセスが行われるまでの第２ステップ（ステップ５０５〜ステップ５１１）との大きく２つのフローがある。

まず第１ステップから説明する。
既に説明の対象とするターゲットシステムのメモリ情報はデバッグ装置の起動時や起動後のユーザのユーザインタフェース操作により図２の状態で設定されているものとする。ここでユーザがコマンド実行やウィンドウ表示・再描画といった操作により、デバッグ装置に対してメモリへのアクセスが要求されると（ステップ５０１）、まずメモリアクセス部２０３はメモリ情報管理部２０１に対して値読み込みまたは書き込みを依頼されたメモリ（アドレス）の状態取得を依頼する（メモリ情報要求）。

依頼されたメモリ情報管理部２０１は、管理するメモリ情報・管理テーブル（図２）から、まず指定されたメモリアドレスを含むアドレス範囲３０２を有するメモリ情報ＩＤ３０１を探す。該当するメモリ情報があった場合、該レコードの状態３０４をもとにメモリアクセス部２０３にメモリのアクセス可・不可状態・情報を返す（ステップ５０２）。

アクセス要求のあったメモリがアクセス可能な状態であった場合（ステップ５０３）、メモリアクセス部２０３は実際のメモリアクセス処理を行う（ステップ５１０）。逆にアクセス不可な状態であった場合（ステップ５０３）、メモリアクセス管理部２０４に対して、メモリアクセス要求の登録を依頼する。

登録依頼されたメモリアクセス管理部２０４は、メモリアクセス要求・管理テーブル（図３）にアクセス要求４０１とメモリ情報ＩＤ４０２を追加登録する（ステップ５０４）。登録は登録依頼順、つまりメモリアクセス要求順としておく。これにより、次に説明する第２ステップの初期設定されアクセス可能となったメモリに対する要求を登録順に処理していけば、実際にユーザなどから要求があったのと同じ順序でアクセスを再現することができる。ここで本発明の第１ステップの処理フローは終わりである。

次に第２ステップを説明する。
先の第１ステップの説明の際、メモリ情報は図２の状態で設定されているものとしたが、メモリ情報管理部２０１はそれを設定されたと同時に、メモリ初期設定検出部２０２に対して初期設定検出方法３０５とその該メモリ情報・ＩＤ３０１を必要な分だけ登録・監視を依頼する。図２のメモリ情報・管理テーブルの例から、既にメモリ初期設定検出部２０２にはメモリ情報・ＩＤ３０１が“４”のＳＤＲＡＭメモリに対する初期設定検出方法が登録されているものとする。

ユーザプログラムが実行中、デバッグ装置ではメモリ初期設定検出部２０２により所定のメモリ（ＳＤＲＡＭメモリ）の初期設定が指定検出方法で監視されている（ステップ５０５）。初期設定が検出された場合（ステップ５０６）、メモリ初期設定検出部２０２はメモリ情報管理部２０１に対して、初期設定されたメモリ情報・ＩＤを通知する。

メモリ情報管理部２０１は、管理するメモリ情報・管理テーブル（図２）のＩＤ３０１と通知を受けたメモリ情報・ＩＤとの一致を検索し、該ＩＤ３０１のレコード内の状態３０４をメモリアクセス可状態へと変更する。その後、メモリアクセス管理部２０４に対して同様に初期設定されたメモリ情報・ＩＤを通知する。

初期設定通知を受けたメモリアクセス管理部２０４は、通知されたメモリ情報・ＩＤに対するメモリアクセス要求がメモリアクセス要求・管理テーブル（図３）に登録されているかどうかを確認する（ステップ５０７，５０８）。該当する登録が無い場合は、他のメモリ初期設定の監視状態（ステップ５０５）に戻る。該当する登録があった場合、その登録のアクセス要求４０１をメモリアクセス部２０３に対して要求し、その登録を管理テーブル（図３）から削除する（ステップ５０９）。これを該当が登録分だけ繰り返す。

この後の処理は、第１ステップで説明したステップ５０１から５０３と行われ、ここでアクセスが可能な状態の場合のステップ５１０へと移り、実際のメモリアクセスが実行される。メモリアクセスの結果は、アクセス要求の内容から最初の要求先へと戻される。これで一連のアクセス要求の処理が終了したことになる（ステップ５１１）。

尚、ここまで説明したメモリアクセス方法にかかる第１のステップと第２のステップとは、それぞれユーザなどからの要求とメモリの初期設定の検出を機に、各々独立した形で処理が行われる。

上記実施の形態１によれば、ユーザがアクセスした際に初期設定前でアクセスできない状態であった場合でも、アクセス可能となった時点で自動的に再度要求を処理するため、ユーザはメモリの状態を意識することなくデバッグ装置の操作ができ、再操作するなどの手間・負担を軽減することができる。また適切な時点で確実にメモリへのアクセスを行うことが可能となる。

またアクセス要求のあったメモリの状態が初期設定されていないアクセス不可状態であった場合、実際のメモリへのアクセスを行わないことにより、メモリアクセスに伴う無駄なシーケンス中の待ち時間を省くことできる。また、初期設定されていない旨をユーザに通知することで、単なるメモリアクセスが失敗しただけでない付加的な情報を与えることが可能となり、その後の再度の無駄なメモリアクセスの要求を抑制することが可能となる。

なお、上記実施の形態１では、メモリ初期設定検出部２０２を特に限定していない。特定の機能ではなく、メモリのアクセスができるようになることが確認できる（実際にメモリアクセスしできるかどうかで判断する等）、またはそれと同等の方法（初期設定処理の後に実行されるアドレスがフェッチされたかどうか、または初期設定の際に必ずアクセスされるデータアドレスがアクセスされたどうか等）であれば何でもよい。

また上記実施の形態１では、メモリアクセス部２０３で該メモリの状態がアクセス不可であった場合、アクセス要求をメモリアクセス管理部２０４で管理、アクセス可能となったときに再度アクセスするものとしたが、メモリアクセス部２０３にアクセスを要求するユーザインタフェースなどの性質により再アクセスを必要としない場合もあるため、その旨を指定することによりメモリアクセス管理部２０４への登録をしなくてもよい。

また上記実施の形態１では、メモリ情報・管理テーブル、メモリアクセス要求・管理テーブル、メモリ初期設定検出方法・管理テーブルの一例として図２，３などで具体的に示したが、管理方法はこれにこだわらず各登録情報が区別できればどんな形式でもよい。また各テーブルの関連リンク付けをメモリ情報・ＩＤで行ったが、これも特に限定するものではない。
［実施の形態２］
図５は、本発明の実施の形態２におけるデバッグ装置の構成図であり、メモリアクセス方法の実現のための構成を示すものである。同図において、メモリ初期設定検出部２０２、メモリアクセス部２０３、メモリアクセス管理部２０４は先に説明した実施の形態１のメモリアクセス方法と同じ機能を有する。新たに、メモリアクセス設定部８０１が備えられている。

またメモリ情報管理部２０１はユーザなどによって登録されるデバッグ対象となるターゲットシステムのメモリ情報を管理する。図６はこの登録・管理されているメモリ情報・管理テーブルの一例を示す。本実施の形態２では、図２で示したメモリ情報・管理テーブルの例に加えて、メモリのアクセス可状態にするための手段である初期設定処理方法９０１を有するものとする。

メモリアクセス設定部８０１には、メモリ情報管理部２０１において管理されているメモリ情報・管理テーブル（図６）のメモリ情報ＩＤ３０１および初期設定処理方法９０１が設定される。

以上のように構成された本発明の実施の形態２におけるメモリアクセス方法について、図３，５，６および図７のフローチャートを用いて説明する。尚、説明は実施の形態１と重複する部分については説明を省略する。

既に説明の対象とするターゲットシステムのメモリ情報はデバッグ装置の起動時や起動後のユーザのユーザインタフェース操作により図６の状態で設定されているものとする。また前記実施の形態１のメモリ情報管理部２０１への設定と同時に、メモリごとの初期設定のための手段であるメモリ情報・管理テーブル（図６）のメモリ情報ＩＤ３０１および初期設定処理方法９０１がメモリアクセス設定部８０１に設定され、管理されるものとする。

本発明の実施の形態１との違いは、アクセス対象のメモリがアクセス不可状態と判断された場合になる。アクセス不可な状態であった場合（ステップ５０３）、メモリアクセス要求の登録を依頼されたメモリアクセス管理部２０４は、メモリアクセス要求・管理テーブル（図３）にアクセス要求４０１とメモリ情報ＩＤ４０２を追加登録する（ステップ５０４）、それと同時に、アクセス要求対象となるメモリがアクセス可能となるようにメモリアクセス要求・管理テーブル（図３）に新規に登録されたメモリ情報ＩＤをもってメモリアクセス設定部８０１に初期設定を依頼する。

メモリアクセス設定部８０１は、管理テーブルから指定メモリ情報ＩＤのメモリ初期設定処理方法を実行する（ステップ１００１）。これでメモリが初期設定されアクセス可能な状態となる。この状態を実施の形態１と同様に、メモリ初期設定検出部２０２が検出し、メモリ情報管理部２０１、メモリアクセス管理部２０４へと初期設定が行われていたメモリの情報が通知され、メモリアクセス部２０３に再度アクセス要求がなされて実際のメモリにアクセスする。実際にメモリにアクセスした後は、メモリアクセス前と同様に管理テーブルから指定メモリ情報ＩＤのメモリ初期設定処理方法（後処理）を実行し、メモリの状態を初期設定前の状態に戻す（ステップ１００２）。

上記実施の形態２によって、メモリアクセス部２０３からアクセス不可を通知されたアクセス要求情報がメモリアクセス管理部２０４に登録された際に、メモリアクセス管理部２０４はメモリアクセス設定部８０１に該メモリ領域へのアクセスを可能とする処理の実行を依頼する。メモリアクセス設定部８０１によりメモリ領域のアクセスが可能とされ、メモリアクセス管理部２０４はメモリ情報管理部２０１からメモリアクセスが可能な状態を示すメモリ状態変更通知を受けた際に、実行可能となったメモリアクセス要求情報をメモリアクセス部２０３に渡してメモリアクセスを実行させる。したがって、ユーザがアクセスした際に初期設定前でアクセスできない状態であった場合でも、あらかじめ定義しておいたメモリ情報の初期設定処理方法９０１を使ってデバッグ装置から直接メモリの初期設定し、メモリをアクセス可能にした上でアクセス要求を処理するため、ユーザはメモリの状態を意識することなくデバッグ装置の操作ができ、再操作するなどの手間・負担を軽減することができる。
［実施の形態３］
図８は、本発明の実施の形態４におけるデバッグ装置の構成図であり、メモリアクセス方法の実現のための構成を示している。同図において、メモリ初期設定検出部２０２、メモリアクセス部２０３、メモリアクセス管理部２０４、メモリアクセス設定部８０１は先に説明した実施の形態２のメモリアクセス方法と同じ機能を有する。新たに、メモリ表示ＵＩ（ユーザインタフェース；User Interface）部１１０１が備えられている。

メモリ情報管理部２０１は、ユーザなどによって登録されるデバッグ対象となるターゲットシステムのメモリ情報を管理し、またメモリの情報登録時やメモリ初期設定検出部２０２からの検出イベント（監視検出通知）によってメモリ情報・管理テーブル（図２または図６）の状態３０４に変化があった場合、メモリ表示ＵＩ部１１０１に状態３０４の変化値と該メモリのアドレス範囲３０２を表示抑制情報として提供する。

メモリ表示ＵＩ部１１０１は、ユーザなどのメモリを読み書きするＵＩを操作した際、メモリ情報管理部２０１からの表示抑制情報をもとにアクセスするメモリがアクセス可能かどうかを判断、可能な場合はメモリアクセス部２０３にメモリアクセスを依頼する。また、逆に不可な場合はメモリアクセス部２０３へのアクセス要求をしない制御を行う。

またメモリ情報管理部２０１から表示抑制情報を受けた時点でメモリ表示ＵＩ部１１０１は、値を表示する場合はそのアドレスがアクセス不可なメモリであることが分かるよう表示を行う。値の書き替えについてもＵＩとして抑制する。例えば、ソフトウェアブレーク設定の場合であれば、通常デバッグ情報から各ソース行に設定可能かどうかのマークをつけるが、本発明の実施の形態３ではデバッグ情報と表示抑制情報からマークをつけるかどうかを行う。具体的には、デバッグ情報としてはそのソース行は有効であってもロードされるメモリが現在アクセス不可な状態であれば設定可なマークはつけないことになる。表示抑制情報の更新のたびに、前回抑制されていた表示が解除されることによりそのアドレス範囲に対するＵＩ抑制も解除することになる。

メモリ表示ＵＩ部１１０１からメモリアクセス部２０３へアクセス要求がされた後のフローは、実施の形態１と同じである。
上記実施の形態３によれば、メモリの状態に応じてメモリ表示ＵＩ部１１０１のメモリ値の表示を変化させることにより、予めユーザからのアクセス要求自体を抑制することができ、無駄なメモリアクセスに関する処理を無くすことが可能となり、またＵＩとしてメモリアクセス部２０３への無駄なアクセス要求がされないため、初期設定が必要なメモリでアクセス不可状態におけるアクセス要求にかかる処理フローがされず、デバッグ装置はより軽快に動作することができる。また、デバッグ装置を利用するユーザの立場としても、ＵＩの段階で表示の抑制がされているので直感的で分かりやすくなる。
［実施の形態４］
図９は、本発明の実施の形態４におけるデバッグ装置の構成図であり、メモリアクセス方法の具体例として、デバッグ装置のソフトウェアブレーク機能の実現のための構成を示している。同図において、メモリ情報管理部２０１、メモリ初期設定検出部２０２、メモリアクセス部２０３、メモリアクセス管理部２０４、メモリアクセス設定部８０１、メモリ表示ＵＩ部１１０１は先に説明した実施の形態１〜３のメモリアクセス方法と同じ機能を有する。新たに、ソフトウェアブレーク管理部６０１と、ユーザプログラム実行制御部６０２が備えられている。

ソフトウェアブレーク管理部６０１は、ユーザ等が指定したソフトウェアブレークの設定を管理する。図１０はこの管理されているソフトウェアブレーク・管理テーブルの一例を示す。ここでは、ブレーク番号７０１は複数のソフトウェアブレークを管理するためのＩＤ、アドレス７０２はソフトウェアブレークを設定するアドレス値、状態７０３はブレーク設定の有効／無効状態、退避コード７０４はソフトウェアブレークを設定したアドレスにあった元の命令コードをそれぞれあらわすものとする。

ユーザプログラム（ＰＧ）実行制御部６０２は、ユーザプログラムの実行及び停止に関する処理全体を制御する。
以上のように構成された本発明の実施の形態４におけるソフトウェアブレーク方法について、図９，１０を用いて説明する。尚、説明は実施の形態１〜実施の形態３と重複する部分については説明を省略する。

本実施の形態４の場合、先の実施の形態１の図４のフローチャートにおけるメモリへのアクセス要求５０１にあたるのが、ユーザのデバッグ装置の操作によるソフトウェアブレークの設定である。ユーザがソフトウェアブレークを設定すると、ソフトウェアブレーク管理部６０１はソフトウェアブレーク・管理テーブル（図１０）にブレーク設定を追加する。追加したブレーク設定のアドレス７０２および状態７０３にはそれぞれ、ユーザから指定された値を格納する。

ユーザによるソフトウェアブレーク設定の操作としては、この他既存のブレーク設定の状態（有効、無効）変更や削除があり、ソフトウェアブレーク管理部６０１が状態変更の場合は指定ＩＤ・番号７０１のブレーク設定の状態７０３を変更、またはブレーク設定自体をソフトウェアブレーク・管理テーブル（図１０）から削除する。

ソフトウェアブレーク機能は特殊なブレーク命令コードをメモリに書き込み、そのコードを実行させることでユーザプログラムを停止させるものだが、ユーザがソフトウェアブレークを設定するなどしている段階では基本的にメモリへの書込みなどのアクセスは発生せず、実際に特殊なブレーク命令コードを書込む等はユーザプログラムの実行の際に行われる。

ユーザがソフトウェアブレークなどデバッグのための準備を整えた後、ユーザプログラムの実行をデバッグ装置に依頼すると、ユーザＰＧ実行制御部６０２はソフトウェアブレーク管理部６０１にソフトウェアブレークの実行前処理を依頼する。ソフトウェアブレークの実行前処理とは、有効状態のソフトウェアブレーク設定について指定アドレスの元命令コードの退避（読み込み）とブレーク命令コードの書込みである。

ソフトウェアブレーク管理部６０１は、ソフトウェアブレーク・管理テーブル（図１０）に登録されているソフトウェアブレーク設定のうち、状態７０３が有効状態となっている設定を探す。そしてそのソフトウェアブレーク設定のアドレス７０２にあるメモリの値（元の命令コード）読み込みをメモリアクセス部２０３に要求する。

メモリアクセス部２０３は先の実施の形態１での説明と同様の処理を行い、ソフトウェアブレーク管理部６０１に対して、アクセス要求された該メモリがアクセス可能な状態であった場合は指定アドレスのメモリの値を、アクセス不可な状態であった場合はアクセス失敗の旨を戻す。

メモリアクセス部２０３からアクセス要求に対する返信を受けたソフトウェアブレーク管理部６０１は、アクセス成功の場合はアクセス要求の元となったソフトウェアブレーク設定の退避コード７０４にメモリの値を格納し、再度同じアドレスに対して特殊なブレーク命令コードの書き込みを要求する。アクセス失敗の場合はソフトウェアブレーク設定の状態７０３を不可状態に変更する。

この１つの有効状態のソフトウェアブレーク設定に対する処理を、ソフトウェアブレーク・管理テーブル（図１０）内で状態７０３が有効状態である登録分だけ繰り返し、ソフトウェアブレークの実行前処理は終了となり、ユーザＰＧ実行制御部６０２はこのソフトウェアブレーク実行前処理が完了したことを踏まえて、ユーザプログラムを実行させる。

先の実施の形態１で説明した通り、ユーザプログラムが実行中、メモリ初期設定検出部２０２はメモリ情報管理部２０１から指示されたメモリ初期設定検出方法により、初期設定がされメモリがアクセス可能な状態になったかどうかを監視しており、また実施の形態２で説明した通り、ユーザがアクセスした際に初期設定前でアクセスできない状態であった場合、メモリアクセス設定部８０１は管理テーブルから指定メモリ情報ＩＤのメモリ初期設定処理方法９０１を実行し、メモリはアクセス可能にされる。メモリ初期設定検出部２０２によりアクセス可能となった状態を検出した後、メモリ情報管理部２０１からメモリアクセス管理部２０４へその旨が通知され、そしてメモリアクセス管理部２０４は該メモリに関連する管理中のアクセス要求をメモリアクセス部２０３に再度要求し、メモリアクセス部２０３は要求に応じてメモリアクセスを実行してその結果を当初のメモリアクセスを要求した要求先に返す。

ソフトウェアブレーク管理部６０１がユーザプログラム実行前に行った実行前処理の中でメモリアクセス時に該メモリがアクセス不可状態であった際にメモリアクセス管理部２０４に登録・管理されていたアクセス要求についても同様に、メモリアクセス部２０３により再度メモリアクセス要求が処理され、要求元であるソフトウェアブレーク管理部６０１にそのメモリアクセスの結果が通知されてくることになる。

通知を受けたソフトウェアブレーク管理部６０１は通知された結果よりアクセス要求の元となったソフトウェアブレーク・管理テーブル（図１０）の中のソフトウェアブレーク設定を特定し、その特定されたソフトウェアブレーク設定に対する該当アドレスの元の命令コードの読み込み（退避）から特殊なブレーク命令コードの書き込みまでの一連の処理の処理を改めて実施するとともに、状態７０３を不可状態から有効状態にし、ソフトウェアブレーク設定を機能させる。

ユーザがブレーク設定した条件が一致、またはユーザが強制的に停止を指示など何らかの要因でユーザプログラムの実行が停止すると、ユーザＰＧ実行制御部６０２はユーザプログラムが停止したことを検知し、ソフトウェアブレーク管理部６０１に対して、ソフトウェアブレークのユーザプログラム実行停止処理を依頼する。ソフトウェアブレークのユーザプログラム実行停止処理とは、ソフトウェアブレークの実行前処理とは逆に、有効状態のソフトウェアブレーク設定について退避しておいた退避コード７０４をアドレス７０２にある指定アドレス先に書込むことである。この書込みもメモリアクセス部２０３に対してアクセス要求を出すことで実現する。

上記実施の形態４によって、ユーザが設定・使用するソフトウェアブレーク機能によってデバッグ装置内部処理的に行われるメモリアクセスにおいてもメモリアクセスが可能な状態となった時点で自動的に所定のメモリアクセスがされることにより、ソフトウェアブレーク機能が有効となるため、ユーザはメモリの状態やデバッグ装置の内部的な処理を意識することなくデバッグ装置の操作ができる。またメモリアクセスが不可なとき、ソフトウェアブレークコードの書き込みや元コードの読み込みといった無駄なメモリアクセスをなくすことができる。

なお、上記実施の形態４では、ソフトウェアブレークの設定をユーザがデバッグ装置を操作することによるものとしたが、ソフトウェアブレークはデバッグ装置の内部的な処理で使われる場合もあり、本発明ではソフトウェアブレークの設定方法は特に限定するものではない。

なお、デバッグ装置の各機能は、プログラムで実現することができる。

本発明にかかるデバッグ装置は、メモリアクセスするために初期設定が必要なメモリを搭載したターゲットシステム上で動作するプログラムのデバッグにおいて、メモリアクセスを要求した時点でアクセス不可であった場合でも無駄に時間を費やすことなく、加えて再度適切な時点でメモリアクセスをする等、通常のメモリと同様に特殊なメモリに対しても通常のメモリアクセス機能を利用する場合に有用である。また、ソフトウェアブレーク機能などメモリアクセス処理を有する他のデバッグ機能を特殊なメモリを搭載したターゲットシステムで通常通り利用する用途にも有用である。

本発明の実施の形態１におけるデバッグ装置の構成図である。 同デバッグ装置のメモリ情報・管理テーブルの一例を示す図である。 同デバッグ装置のメモリアクセス要求・管理テーブルの一例を示す図である。 同デバッグ装置の処理の流れを示すフローチャートである。 本発明の実施の形態２におけるデバッグ装置の構成図である。 同デバッグ装置のメモリ情報・管理テーブルの一例を示す図である。 同デバッグ装置の処理の流れを示すフローチャートである。 本発明の実施の形態３におけるデバッグ装置の構成図である。 本発明の実施の形態４におけるデバッグ装置の構成図である。 同デバッグ装置のソフトウェアブレーク・管理テーブルの一例を示す図である。 従来の課題を示すユーザＰＧとデバッグ装置とのシーケンス・関連図である。

符号の説明

２０１ メモリ情報管理部
２０２ メモリ初期設定検出部
２０３ メモリアクセス部
２０４ メモリアクセス管理部
３０１ メモリ情報・ＩＤ（管理番号）
３０２ メモリ情報・アドレス範囲
３０３ メモリ情報・メモリ種別
３０４ メモリ情報・状態
３０５ メモリ情報・初期設定検出方法
４０１ メモリアクセス要求・アクセス要求
４０２ メモリアクセス要求・メモリ情報ＩＤ
６０１ ソフトウェアブレーク管理部
６０２ ユーザＰＧ実行制御部
７０１ ソフトウェアブレーク・ＩＤ（管理番号）
７０２ ソフトウェアブレーク・アドレス
７０３ ソフトウェアブレーク・状態
７０４ ソフトウェアブレーク・退避コード
８０１ メモリアクセス設定部
９０１ 初期設定処理方法
１１０１ メモリ表示ＵＩ部

Claims (17)

1. 初期設定を要するメモリ上で動作するプログラムをデバッグ対象とするデバッグ装置であって、
   前記メモリの情報として、予め前記メモリの領域、メモリ種別、メモリの初期設定検出方法が登録され、現在の前記メモリへのアクセス可／不可状態情報を管理し、前記メモリへのアクセス要求に応じて、前記登録されたメモリの初期設定検出方法を出力するメモリ情報管理部と、
   前記メモリ情報管理部より出力されるメモリの初期設定検出方法により前記メモリへのアクセスが可能かどうかを検出し、その結果を前記メモリ情報管理部へ出力し、アクセス可／不可状態情報を更新させるメモリ初期設定検出部と、
   前記メモリへのアクセス要求を入力すると、このアクセス要求のメモリが、前記メモリ情報管理部のアクセス可／不可状態情報によりアクセス可能かどうかを確認し、アクセス可のとき前記アクセス要求に基づいてメモリへの読み書きを行い、アクセス不可のとき即座に前記メモリへのアクセス不可を通知するメモリアクセス部と
   を備えることを特徴とするデバッグ装置。
2. 前記メモリアクセス部からアクセス不可が通知されたアクセス要求を管理し、前記メモリ初期設定検出部により前記アクセス不可のメモリがアクセス可能と検出されて前記メモリ情報管理部のアクセス可／不可状態情報が更新されると、再度、前記メモリアクセス部に対して管理しているアクセス要求を出力するメモリアクセス管理部
   を備えることを特徴とする請求項１に記載のデバッグ装置。
3. 前記メモリのアクセスを可能にするための設定情報を管理し、要求に応じて前記メモリの初期設定を行いアクセスを行えるようにするメモリアクセス設定部を備え、
   前記メモリアクセス管理部は、前記メモリアクセス部からアクセス不可が通知されると、前記メモリアクセス設定部へ前記メモリの初期設定を要求し、前記メモリアクセス設定部は、前記要求があった際に前記設定情報を実行して前記メモリをアクセス可能にし、その上でアクセス要求が処理されること
   を特徴とする請求項２に記載のデバッグ装置。
4. 前記メモリの値を表示するメモリ表示ユーザーインターフェイス部を備え、
   前記メモリ情報管理部は、メモリ情報が登録されたとき、または前記メモリ初期設定検出部から検出イベントを受けたとき、前記メモリ表示ユーザーインターフェイス部に表示抑制を要求し、前記メモリ表示ユーザーインターフェイス部は、この表示抑制に基づいて、メモリアクセス要求がされないようメモリ表示方法を変えること
   を特徴とする請求項１〜請求項３のいずれか１項に記載のデバッグ装置。
5. ユーザプログラムの実行を制御および監視するユーザプログラム実行制御部と、
   ソフトウェアブレークを設定するアドレス値が登録され、前記ユーザプログラム実行制御部からプログラム実行開始前処理が依頼されると、前記ソフトウェアブレークのアドレスの命令コードの退避およびブレーク割込み命令の書き込みを、前記メモリアクセス部を介して前記メモリがアクセス可状態の時点で実行し、前記ユーザプログラム実行制御部からプログラム停止処置が依頼されると、前記退避していた命令コードの元のアドレスへの書き込みを、前記メモリアクセス部を介して実行するソフトブレーク管理部と
   を備えることを特徴とする請求項１〜請求項４のいずれか１項に記載のデバッグ装置。
6. 前記メモリ初期設定検出部は命令実行アドレスイベント機能であり、
   前記メモリ情報管理部からの実行命令アドレスを含む検出方法情報をもとに監視状態になり、条件が成立して検出した場合に前記メモリ情報管理部へ通知すること
   を特徴とする請求項１〜請求項５のいずれか１項に記載のデバッグ装置。
7. 前記メモリ初期設定検出部はデータアクセスイベント機能であり、
   前記メモリ情報管理部からのデータアクセスアドレス及びデータ値を含む検出方法情報をもとに監視状態になり、条件が成立して検出した場合に前記メモリ情報管理部へ通知すること
   を特徴とする請求項１〜請求項５のいずれか１項に記載のデバッグ装置。
8. 前記メモリ初期設定検出部はメモリアクセスのポーリング機能であり、
   前記メモリ情報管理部からのアクセスアドレスを含む検出方法情報をもとに監視状態になり、実際に指定アドレスに対するアクセスが可能となった場合に前記メモリ情報管理部へ通知すること
   を特徴とする請求項１〜請求項５のいずれか１項に記載のデバッグ装置。
9. 初期設定を要するメモリ上で動作するプログラムを有するシステムを対象とするメモリアクセス方法であって、
   前記メモリへのアクセスが要求されると、前記メモリへのアクセスが可能かどうかを検出し、
   前記メモリがアクセス不可状態であったとき、前記アクセスを実行せず、即座にメモリアクセス不可を通知すること
   を特徴とするメモリアクセス方法。
10. 前記メモリがアクセス不可状態であったとき、このアクセス要求を一旦登録し、
    前記メモリがアクセス可状態となると、前記登録していたアクセス要求を再実行すること
    を特徴とする請求項９に記載のメモリアクセス方法。
11. 前記メモリがアクセス不可状態であったとき、このメモリをアクセス可能とする処理を実行し、
    前記メモリがアクセス可状態となると、前記登録していたアクセス要求を再実行すること
    を特徴とする請求項１０に記載のメモリアクセス方法。
12. 前記検出されるメモリのアクセス可／不可状態に応じて、ユーザによる操作を抑制してメモリアクセスが要求されないようメモリ表示方法を変えること
    を特徴とする請求項９〜請求項１１のいずれか１項に記載のメモリアクセス方法。
13. ソフトウェアブレークの設定処理に際して、前記メモリへのアクセスが可能かどうかを検出し、前記メモリがアクセス不可状態であったとき、アクセス可能状態になった時点で再度設定処理を行うこと
    を特徴とする請求項９〜請求項１２のいずれか１項に記載のメモリアクセス方法。
14. 前記メモリへのアクセスが可能かどうかの検出を、命令実行アドレスイベント機能により行うこと
    を特徴とする請求項９〜請求項１３のいずれか１項に記載のメモリアクセス方法。
15. 前記メモリへのアクセスが可能かどうかの検出を、データアクセスイベント機能により行うこと
    を特徴とする請求項９〜請求項１３のいずれか１項に記載のメモリアクセス方法。
16. 前記メモリへのアクセスが可能かどうかの検出を、メモリアクセスのポーリング機能により行うこと
    を特徴とする請求項９〜請求項１３のいずれか１項に記載のメモリアクセス方法。
17. 請求項９〜請求項１６のいずれか１項に記載のメモリアクセス方法の少なくともひとつをコンピュータに実行させること
    を特徴とするプログラム。
    

Images