JP3965142B2 - コンピュータ・プログラムをデバックするための方法、システムおよびソフトウェア・プロダクト - Google Patents

Description

本発明はデバッガにおけるブレークポイントの使用に関し、より詳細には、時間ベースのブレークを開始するためのデバッガの使用に関する。

デバッガは、開発者が既存のコードをコーディングし、維持する際になくてはならないツールである。従来のデバッガは、プログラマが存在しているバグを除去する際に、あるいは、プログラムの動作を理解する際に役立つ多くの機能をプログラマに提供している。デバッガの従来の特徴の１つは、ブレークポイントと呼ばれるものを挿入する手段である。

表１は、さまざまな種類のブレークポイントと、それらがどのように動作するかを一覧表にしたものである。プログラマが１行ごとにコード内に進むことができるように、または、必要に応じてプログラム実行を再開することができるように、プログラムの実行はブレークポイントで停止する。ブレークポイントが動作しているときに、プログラマは、実行されているコードの各行のプログラム変数の値を決定することができる。

ブレークポイントは、どのデバッガにおいても最も使用されている機能である。現在のデバッガは、多くの種類のブレークポイントを提供している。デバッガは、一般に、到達したブレークポイントの種類に応じて、プログラム実行を停止する。

従来のデバッガに関連する欠点の１つは、所定の時間が経過した後にプログラム実行を停止するブレークポイントがないことである。すなわち、所定の時間が経過した後にのみ効力を発するブレークポイントがない。それと同じ効果を達成するために使用されている２つの次善策がある。以下に、それらについて簡単に説明する。

第１の次善策は、手動で時間の経過を追跡し、指定した時間が経過するとプログラムを中断することを必要とする。この技法は、特に時間遅延がきわめて小さい場合には不正確である。さらに、プログラマは、手動で時間を追跡することを要求される。したがって、この技法は比較的難しく、エラーが生じやすい。時間遅延が大きい場合には、プログラマがプログラム実行を中断しなかった場合には、プロセス全体をもう一度繰り返す必要が生じることがある。

第２の次善策は、オリジナル・コードを、表２に示すコードのような追加コードを加えて再プログラミングすることを含む。

コードを表２に示す追加ステートメントとともに再コンパイルし、「ダミーステートメント」の位置でブレークポイントを設定すると、同じ効果が得られる。

しかし、この技法に特有の欠点は、ソース・ファイルを変更する必要があることである。構築手順に長時間かかる場合には、コードを変更して再構築するプロセスは望ましくない。さらに、プログラマは、リリースまたは「生産準備」構築のために、上記コードを注意深く除去しなければならない。

上記を鑑みると、明らかに、コンピュータ・プログラムをデバッグする際に使用する、時間ベース・ブレークポイントを提供するための改良された方法が求められている。

プログラマが、コードのどの行にでも時間ベース・ブレークポイントを設定できるようにする、時間ベース・ブレークポイント機能をデバッガに提供する。行が実行されて、指定した時間が経過すると、プログラム実行は必然的に停止する。デバッガは、このようなブレークポイントのそれぞれについて、経過した時間を追跡する。各ブレークポイントの時間を計算するための基準は数多く存在する可能性がある。

ブレークポイントのタイマを、プログラムが実行開始したときに開始させることができる。ブレークポイントのタイマを、（ブレークポイントを含む）行に初めて到達したときに開始させることもできる。ブレークポイントのタイマを、プロセスが得るＣＰＵ時間に基づかせることも可能である。

このデバッガは、各ブレークポイントの時間計算を、プログラムの実行が別のブレークポイントのために停止すると必ず処理する。ブレークポイントは、所定の時間が経過した後に効力を発し、効力を発する前は機能していない。

時間ベース・ブレークポイントを既存のブレークポイントと結合することによって、さらなる機能およびフレキシビリティをプログラマに提供することができる。特定の条件または記憶の変更などのその他のパラメータよりも、「時間」がプログラムの実行を中断するための好ましいパラメータである場合には、時間ベース・ブレークポイントが役に立つ。

デバッグとは、メモリ内容を観察することによって、またはプログラムの実行の流れを観察することによって、プログラムからバグを除去するプロセスを表す。デバッグ・プロセスは、ソース・ファイルのコンパイルの間に検出されなかった論理エラーを、捜し出して訂正する際の助けとなる。デバッガは、このプロセスを容易にし、コード中の諸位置において、プログラマが指示するとプログラム実行を中断するツールである。このタイプのデバッグ技術を対話型デバッグと呼ぶ。対話型デバッグでは、デバッガが、デバッグされているプログラムの実行を中断し、また、プログラマがユーザ・インタフェースを介してデバッガと対話することを可能にする。

この技術はまた、ブレークポイント・デバッグとも呼ばれる。デバッガが、プログラマがプログラム中にブレークポイントを設定できるようにすることによってプログラム実行を一時停止し、また、プログラマがプログラム状態を観察し、変更することを可能にするからである。

プログラム状態は、どの段階においても、レジスタ値、およびプログラムのデータを記憶するために使用されるメモリ内容を含む。デバッガは、スピードおよび単純化のために、プログラマが、直接、ソース・コードにブレークポイントを設定できるようにする。ソース・コードは、デバッグ情報と呼ばれる、プログラム・ファイル中に記憶されている追加情報を使用することにより、機械語命令にマップされる。このデバッグ情報は、同じファイルに含めてもよいし、または別個のファイルとしてもよい。

適切なオプションを使ってソース・ファイルをコンパイルすると、通常、このデバッグ情報が生成される。したがって、デバッガは、ソース・コード情報を、対応する機械語レベルの命令にマップすることができる。ソース・コードはソース・ファイル中に含まれているが、一方、機械語命令は、プログラムの実行可能ファイル中に記憶される。コンパイル・プロセス、およびその後のリンキングによって、ソース・コード命令は機械語命令に変換される。コンパイル・プロセスによって生成されるデバッグ情報の一部を使って、ソース・レベルの命令を機械語命令に、また機械語命令をソース・レベルの命令にマップする。

デバッガはこの情報をファイルから読み取り、その情報を、構造体の配列、ツリー、ハッシュ・テーブルなどの適切なデータ構造中に置く。このデータ構造は、デバッガがメモリ内でプログラムの実行可能イメージ中にブレークポイントを挿入する際に、ソース・コードを機械語コードに関連付けるために使用される。

ブレークポイントは、コンパイル時ではなく、デバッガの実行時にプログラムがメモリ中にあるときに設定される。ブレークポイントは、プログラムが開始するとメモリ中で設定される。プログラムが実行を一時停止して、プログラマがメモリを調べたり、新しいブレークポイントを設定したりするなどのデバッグ操作を完了するのを待っている間にも、新しいブレークポイントを挿入することができる。このブレークポイントを設定するプロセスはユーザ・インタフェースを介して行われ、このユーザ・インタフェースによって、プログラマがデバッガを出るときにブレークポイント・リストの格納も行われる。そのため、次のセッションの間にプログラムをデバッグする際、ブレークポイントが失われることはない。

デバッグのプロセスは、１つのプログラムが別のプログラムの実行を制御することを含む。制御するプログラムがデバッガであり、制御されるプログラムがデバッグされるプログラムである。これはマスタ・スレーブ関係の形態であり、デバッガは、プログラマのニーズに応じて実行の流れを制御する。したがって、デバッガは、子プログラムのメモリへのアクセス、そこからの読取り、およびそこへの書込みができなければならない。デバッガが、子プログラムの機械語命令、レジスタ値、または変数の読取りまたは書込みを行いたいという場合がある。メモリの読取り、およびプログラマへのプログラム状態の報告の他に、デバッガが子のメモリの内容を変更したいという場合もある。この能力は、プログラマがユーザ・インタフェースを使っていくつかの変数またはレジスタに書き込むことを要求する際に、ブレークポイントの設定、またはメモリの変更を行うために必須である。

最新のオペレーティング・システムは、「プロテクト・モード」と呼ばれる特別なモードでプロセッサを動作させる。プロテクト・モードの重要な機能は、メモリの損傷を回避するために、プログラムが別のプログラムのメモリにアクセスすることを許可しないことである。オペレーティング・システムは、プログラムが互いに通信するためのメカニズムを提供する。２つのプロセスを通信させるこの機能をプロセス間通信と呼び、プログラムはこの機能を拡張して使用する。たとえば、あるプログラムが別のプログラムに、イベントが生じたことを通知する必要がある場合がある。このイベントは、ウィンドウのリサイズや資源の解放などであり得る。

これらのイベントは、システムの信号またはメッセージを動作させることによって通信される。信号は、プロセス間通信の１つのモードである。重要なイベントとしては、子プロセスに直ちに実行を一時停止するように通知することが挙げられる。どのプロセスも信号を発生させることができるが、これは、任意の所与の時点で、プログラム実行を直ちに一時停止したいという場合があるデバッガにとっては有用である。これは、例外を発生させるブレーク命令のためにプログラム実行が一時停止する場合には異なる。例外ベースのプロセスの一時停止は、以下に説明するように、ブレークポイントが実装されることを可能にする。

ＵＮＩＸ（Ｒ）ベースのオペレーティング・システムでは、ＳＩＧＳＴＯＰと呼ばれる信号を発生させることによって、瞬時にプロセスが停止する。プロセスは、その信号がプロセスに送達されるとすぐに実行を一時停止するのである。異なるオペレーティング・システムには、対応するメッセージが存在する。前に述べたように、信号とは、２つのプロセスが互いに通信するためのメカニズムである。したがって、あるプロセスが信号を送り、別のプロセスがその信号を受け取る。この信号は、通常、オペレーティング・システムによって経路指定され、それによって正しいプロセスに送られる。カーネルもまたプロセスに信号を送ることによって、不当なメモリ・アクセスや入出力エラーなど、さまざまなイベントをプロセスに通知する。したがって、現在のオペレーティング・システムは、プロセスが別のプロセスに、さらなる通知があるまでその実行を一時停止するように通知できるメカニズムを提供している。

オペレーティング・システムは、ハードウェア・クロックの助けを借りて、システム時間を維持する。内部で、オペレーティング・システムのカーネルがハードウェア・クロックを使って、多重処理システム中のプロセスをスケジュールしている。カーネルはまた、いずれかの時間関連機能のためのプログラムへのシステム・コールを提供する。ユーザは、これらのコールを使って時間を設定し、システム時間を得、または所定の時間間隔で定期的な通知を受けることができる。

オペレーティング・システムはまた、正確さのために、マザーボード・ハードウェア上にリアル・タイム・クロック（ＲＴＣ）へのインタフェースを提供することができる。プログラムは、より高い精度のために、直接、ＲＴＣと通信することができる。したがって、プログラムは、指定した時間が経過したときにそれを通知するよう、オペレーティング・システムまたはＲＴＣに要求することができる。これらのタイマは、指定した時間間隔が経過したときにそれを一度だけプロセスに知らせる「ワン・ショット」タイマであっても、あるいは定期的な間隔でプロセスに信号を送る定期タイマであってもよい。

上述のように、デバッガは、デバッグされている子プロセスを制御する。デバッガはまた、子プロセスに送られる信号を傍受することによって、子プロセスに対する完全な制御を得る。デバッガは、子プロセスに送られるすべての信号を受け取り、プログラマが指示しているかどうかに応じて、それらを子プロセスに向けて経路指定する。ある命令が子プロセス中に例外を発生させた場合には、まず対応する信号がデバッガに送られる。このメカニズムは、ブレーク命令が到達したかどうかを検出する。ブレーク例外は、子プロセスが、プログラマがデバッガを使ってブレークポイントを設定しておいた命令を実行したために、実行を一時停止したことをデバッガに通知する。

ブレークポイントは、ハードウェアとソフトウェアの両方において実装される。デバッガは、通常、総称してブレークポイントとして知られる、これら両方の種類の実装を使用する。ハードウェアによっては、チップの一部であるデバッグ・レジスタを使用してブレークポイントを設定する機能を提供するものもある。これらの種類のブレークポイントは、ハードウェア・ブレークポイントとして知られ、これには（ｉ）データ・ブレークポイントと（ｉｉ）命令ブレークポイントの２種類がある。

データ・ブレークポイントは、指定された記憶域または入出力ポートに対してアクセスがなされたときに、プログラム実行を中断する。命令ブレークポイントは、コード中の指定された位置に到達したときに必ずプログラム実行を停止する。中断の実行により、制御がデバッガ・プロシージャに移る。これは、ハードウェアを使ってなされる。

たとえば、インテルｘ８６中央処理装置アーキテクチャでは、８個のデバッグ・レジスタ（Ｄ０からＤ７まで）がある。４個のレジスタ（すなわちＤ０、Ｄ１、Ｄ２、Ｄ３）は、ブレークポイントを設定するために使用される。これらのレジスタは、ブレークポイントが設定される３２ビットのリニア・アドレスを記憶する。レジスタＤ４およびＤ５は、高度デバッグのために使用される。レジスタＤ６およびＤ７は、それぞれ、ステータスおよび制御デバッグ・レジスタとして動作する。

命令ブレークポイントを設定するには、その命令のアドレスを、Ｄ０からＤ３の未使用のデバッグ・レジスタのうちいずれかに記憶する。Ｄ７を、そのブレークポイントが命令ブレークポイントであることを表すように適切に設定する。ハードウェアは、プロセッサが指定されたアドレスの命令を実行しようとすると、デバッグ例外を投入する。この例外は、その命令が実行される前に投入され、デバッグ・プロシージャは、その例外が再び発生されないように、ブレークポイントをクリアすることを要求される。

これに対して、データ・ブレークポイントの場合は、記憶域または入出力ポートに対してアクセスがなされた後にのみ、トラップ例外が発生する。ハードウェアはまた、子プログラムをシングル・ステップさせるための機械語命令を提供する。

ハードウェア・ブレークポイントの１つの問題は、この機能がハードウェアに依存し、アーキテクチャによってはハードウェア・ブレークポイントをサポートしない場合があることである。ハードウェア・ブレークポイントは数が限られ、したがって、デバッガはソフトウェア・ブレークポイントを実装する。ソフトウェア・ブレークポイントは、デバッグされているプログラムの実行可能コードを変更することによって実装されるブレークポイントである。これは実行可能ファイル上ではなく、メモリにおいてなされる。デバッグされているプログラムのコードは、デバッガによって「パッチ」される。

図１は、プログラムがデバッガで実行されているときに、メモリにおいて、プログラムの実行可能イメージ中にブレークポイントを挿入する際に生じるステップを流れ図で示したものである。

１行のコードにブレークポイントが設定されると、デバッガは、以下の表１に示す次のステップを実行する。

ブレーク命令が例外を発生させると必ず、ブレークポイントにヒットし、またはブレークポイントに到達する。すると、制御がデバッガ・プロシージャに移る。デバッガは、ユーザに、ブレークポイントに到達したことを知らせる。ユーザが実行を続行すると、デバッガはブレーク命令（上述したように、デバッガが前に記憶した命令）を元の命令と置き換えて、その命令を実行する。デバッガは、その命令を実行した後、再び元の命令を記憶して、その元の命令をブレーク命令と置き換える。したがってブレークポイントが失われることはない。これは、ある命令のブレークポイントを使用不能にし、その後、元の命令が実行されると、そのブレークポイントを使用可能にすることと同じである。通常、すべてのブレークポイントは、ヒットすると、ブレーク命令を保持するが、この挙動は、ブレークポイントの種類が異なると異なる場合がある。例えば、一時ブレークポイントは、ヒットしても元の命令をブレーク命令と置き換えることはない。これは、一時ブレークポイントが一度だけ使用できるブレークポイントであり、したがってブレーク命令を保持する必要がないためである。

図２は、図１に流れ図で示したプロシージャの例を略図で表したものである。プログラム・コード・フラグメント２１０は、ブレークポイントを含む。後で、デバッガは、対応する機械語命令２２０中のどこにそのブレークポイントを置くべきかを判断する。図２では、わかりやすいように、例としてアセンブラ命令を使用している。この場合、デバッガは、適切な機械語命令２４０をブレークポイント２３０と置き換え、元の命令２４０をメモリに保存する。

上記に説明したように、デバッガは、コードをパッチし、例外を投げるコードを挿入する必要がある。これは、直接、デバッガが行うことができる。多くのオペレーティング・システムは、プロセスが別のプロセスのアドレス空間にアクセスすることを許可しない。オペレーティング・システムは、通常、デバッガがコードをパッチし、デバッグされているプログラムの変数を読み取ることを可能にするシステム・コール（カーネルにサービスを要求するためのインタフェース）を提供している。システム・コールは、デバッガで実行している子プログラムを制御するメカニズムの働きをする。これによって、デバッガは、例外および信号を傍受して、プログラムに対する完全な制御を得ることができる。

デバッガは、ほとんどすべてのＵＮＩＸ（Ｒ）クローンが提供しているptrace()システム・コールを使用する。ptrace()システム・コールによって、デバッガは、子のアドレス空間中のメモリ、レジスタ、ウォッチ・ポイント（ハードウェア中のデータ・ブレークポイント）などからの読取りまたはそこへの書込みを行うことができる。デバッガは、メモリ中でコードを変更することにより、ソフトウェア・ブレークポイントを設定することができる。または、デバッガは、子プロセスのレジスタを設定することによって、ハードウェア・ブレークポイントを設定することができる。

デバッガでプログラムが実行されると、デバッガは親プログラムとして動作し、その子として、デバッグされているプログラムを作成する。したがって、デバッガとデバッグされるプログラムには親子関係がある。デバッガの主な目的は、子プログラムを制御し、観察することである。したがって、デバッガは、子プログラムを作成した後、子プログラムが実行している間、待機している。オペレーティング・システムは、子プログラムに信号が送達される度に子プログラムを停止する。オペレーティング・システムは、次いで、子が停止したことを親プログラム（この場合、デバッガ）に通知する。デバッガは、子が停止した理由を問い合わせることができる。

プログラマがブレークポイントを挿入し、デバッガでプログラムを実行すると、デバッガは、そのプログラムを子プログラムとして作成し、オペレーティング・システムからの通知を待つ。ブレークポイントに到達すると、プログラムは例外を発生させ、子プログラムは停止状態に移行する。オペレーティング・システムは、子プログラムが停止したことをデバッガに知らせる。すなわち、ブレークポイントに到達すると、制御が子プログラムからデバッガに移る。子が実行している場合、デバッガは、子プログラムで何かイベントが発生するのを無限に待つ。制御がデバッガに移ると、子プロセスはずっと停止した状態にある。

簡単に言えば、以下の機能を成し遂げることができるメカニズムが存在する。
１．デバッガは、コンパイル時に生成されるデバッグ情報を使って、機械語命令をソース・コードに、またソース・コードを機械語にマップすることができる。
２．プロセスは、そうすることを選択した場合にはいつでも、別のプロセスの実行を一時停止することができる。この目的を達成するために、プロセスは、その別のプロセスに通知するためのメカニズムを使用する。例えば、プロセスは、別のプロセスに、オペレーティング・システムが提供する信号を使って通知することができる。
３．デバッガは、子プロセスを完全に制御することができる。これは、どの対話型デバッガにとっても基本的な要件である。
４．オペレーティング・システムは、インタフェースが呼び出すシステム・コールによって、またはプロセスが直接、ハードウェア・クロックと通信できるようにすることによって、タイミング情報をプロセスに提供する。
５．デバッガは、子プロセスのアドレス空間またはレジスタにアクセスし、変更することによって、ハードウェアまたはソフトウェア中にブレークポイントを挿入することができ、また、ハードウェアまたはソフトウェア中のブレークポイントを使用不能にすることができる。これは、直接、子のメモリ（またはレジスタ）を変更することによって、または、オペレーティング・システムにそうすることを要求することによって行うことができる。

説明しているデバッガは、プログラマが停止させたいと思う特定の時点でプログラム実行を停止させることを可能にする。このような、時間がプログラム実行を停止させるパラメータであるブレークポイント・タイプを、ここでは時間ベース・ブレークポイントと呼ぶ。

時間ベース・ブレークポイント
前に述べたように、ブレークポイントを使用して対話型デバッガでプログラム実行を一時停止し、それによって、プログラマが、プログラムの状態および実行の流れを問い合わせることができるようにする。これは、ハードウェア中の特別なレジスタを設定することによって、またはソフトウェア中のメモリをパッチすることによって行われる。時間ベース・ブレークポイントの挿入は、タイマを開始すべき時を検出し、経過した時間を追跡し、次いで、適宜に子プログラムの実行を中断することを含む。

ほとんどのその他のブレークポイントと同様に、時間ベース・ブレークポイントは１行のコードに関連付けられる。該当するコード行が実行されると、対応するタイマが開始される。１行のコードの実行は、タイマのトリガとして動作する。行が実行されると、トリガが起動され、タイマが開始される。時間が経過すると、プログラム実行は停止する。このような影響を得ることに関する詳細を以下に説明する。

トリガ
プログラマがユーザ・インタフェースを介してデバッガにコマンドを与えると、デバッガでプログラムが「実行」される。このコマンドは、デバッガによって提供される、コマンド上にタイプされた“run”や“go”であってよく、あるいは、ショートカット・キーやマウスのクリック動作といった形態であってもよい。プログラムが実行できる状態になると、デバッガは、上述のメカニズムによって、メモリ中で実行可能メモリにブレークポイントを設定する。

ユーザは、ソース・ファイル中に時間ベース・ブレークポイントを設定し、デバッガは、タイマを開始させるトリガの働きをする命令を判断する。子プロセス中で実行されている命令の位置を調べて、その位置をトリガの位置と比較するプロセスは、比較的時間のかかる、非効率的なプロセスであり得る。

したがって、代替技術を使用する。トリガに到達したかどうかを判断する代わりに、トリガが設定されている命令に子プロセスが到達する度に、それを親プロセスに通知する。

図３は、メモリにおいて、プログラムの実行可能イメージにどのようにトリガが挿入されるかに関するステップを流れ図で示したものである。使用される技術は、ブレークポイントの場合に使用されたものと同じであり、したがって、トリガを挿入するために使用されるステップは、ブレークポイントを挿入するために使用されたステップと同じである。図３のこれらのステップを、対応する番号のステップを使って、下記の表４に示す。

図３を参照しながら上記に説明したプロセスは、ブレークポイントの設定とほとんど同じであるため、デバッガは、困難なくトリガを設定することができる。デバッガでプログラムを実行している間にトリガ命令に到達すると、プログラム実行は中断し、それによって、デバッガがタイマを開始できるようにし、プログラマがデバッグ操作を行えないようにする。プログラム実行の一時停止は一時的なものである。デバッガを使用しているプログラマは、プログラムの実行において何も違いに気付くことはない。

トリガ命令は、ブレークポイントのタイマを開始させ、次いで、プログラム実行を再開する。

図４は、プログラム実行中にトリガに遭遇した際に生じるステップを流れ図で示したものである。それらのステップを、対応する番号のステップを使って、下記の表５において説明してある。トリガに到達すると、デバッガはブレーク例外を発生させる。これは、通常のブレークポイントの場合と同じである。

したがって、デバッガは、そのブレーク例外がトリガによって発生したのか、またはブレークポイントによって発生したのかを判断する。トリガがブレーク例外を発生させた場合には、タイマが開始され、プログラム実行は続行される。ブレークポイントがブレーク例外を発生させた場合には、デバッガは、プログラマが通常のデバッグ操作を行えるようにする。

デバッガは、ブレーク命令がトリガかブレークポイントであるかを判断するために、それ自身の時間ベース・ブレークポイント・リストのシンプル・サーチを実行する必要がある。

上述のステップによって、プログラマは、１度だけ使用できるトリガのみを設定することができる。すなわち、ひとたびトリガに到達すると、プログラムを再開始しない限り、そのトリガは失われる。上記のトリガの拡張として、上記ステップ４３０で説明した実行に優先させてトリガを再挿入することにより、循環トリガを実装することができる。これについては下記の表６に説明してある。

図５は、循環トリガを設定するために必要な追加ステップを流れ図で示したものである。循環トリガの場合、タイマがすでに実行中である場合には、そのタイマをどのように開始すべきかに関するポリシーが実装される。デバッガは、このようなトリガを無視することを選択することができ、または、各タイマを再開始することができる。あるいは、各トリガについて異なるタイマを維持することもできる。このようなポリシーの決定、および循環トリガの実装は、上述の「１度だけ使用する」トリガを単純に拡張したものである。

図５は、図４を参照しながら説明したステップ４１０〜４２０およびステップ４４０〜４６０に対応する、ステップ５１０〜５２０およびステップ５４０〜５６０を含む。すなわち、図５は、ステップ４３０を除く、図４のすべてのステップを含む。ステップ４３０は、上記の表６で説明したように、ステップ５３０に置き換えられる。

内部では、ブレークポイントとトリガが、デバッグされているプログラムに例外を発生させ、それによってデバッガにイベントが通知されるようにする。トリガとブレークポイントの両方がブレーク命令を挿入することによって、この効果が成し遂げられる。トリガおよびブレークポイントは、ブレーク命令がヒットされると、異なってくる傾向がある。一方で、ブレークポイントにより、デバッガは制御をユーザ・インタフェース・スレッドに渡し、プログラマがメモリ内容およびレジスタの値を調べることができるようにする。プログラム実行は、プログラマがそうすることを選択した場合にのみ再開する。したがって、プログラマはブレークポイントにヒットしたときいつでも、十分に気付く。

これに対して、トリガは、内部でタイマを開始させ、ユーザ・インタフェース・スレッドに制御を渡すことなくプログラム実行を続行する。時間ベース・ブレークポイントのタイマが開始されるとすぐに、プログラム実行が再開する。プログラム実行の続行はプログラマの入力に依存せず、トリガがヒットしたときにそれをユーザが知らされなくてもトリガの機能は何も失われない。したがって、実際には、ブレークポイントがプログラマのためにプログラム実行を中断し、一方、トリガは、タイマを開始させることができるように、プログラム実行を一時的に中断する。

タイマ
タイマは、トリガに最初に到達してから経過した時間を追跡する、時間ベース・ブレークポイントにおけるエンティティである。タイマは、直接、またはクロックとインタフェースをとるオペレーティング・システムを介して、外部クロックを使用して実施される。

タイマは、経過時間を計算するさまざまな方法、デバッグ操作の間の時間の計算、および指定した時間が経過したときに実行すべき動作を提供することができる。これらの態様のそれぞれについて以下に説明する。

プログラマは、タイマが開始してからの時間を計算するための自分が望む技術を選択する。選択する技術は、そのプログラマの特定のニーズに完全に依存する。

マルチプログラミング環境においては、通常、プログラムにはＣＰＵ（中央処理装置）の全処理時間が割り振られることはない。その代わりに、プログラムは、「タイム・スライス」と呼ばれる、合計使用可能時間のほんの一部を使用するだけである。タイム・スライシングは、ＣＰＵが１つしかない場合でも、多くのプロセスが同時に実行しているように見せる。

以下は、時間計算のための異なる技術の例である。
（ｉ）経過した時間の「ウォール・クロック」時間追跡。この時間計算は、外部のエンティティが正確なストップウォッチを使って経過した時間を計算しているかのように行われる。
（ｉｉ）プログラムが実行されている間に経過した時間に基づいて計算がなされる。これは、プロセスがタイム・スライスの自分の割当て分を得ている間のみ、時間計算が行われることを意味する。これは、（デバッグされている）プロセスにＣＰＵ時間が割り振られている場合にのみ実行する、外部の正確なストップウォッチと似ている。その他のプロセスがＣＰＵ時間を得ている場合、ストップウォッチは一時停止状態にある。
（ｉｉｉ）プログラムが実行している間に経過した時間、およびカーネルがプロセスのために要求を実行するのにかかる時間。カーネルはプロセスの要求を実行するために多くの低レベル・ジョブを行う。これは、低レベルの破損（メモリ、ハードディスク上のファイルなどの破損）を防ぐために、プロセスのために行われる。この技術は、技術（ｉｉ）と同様である。ただし、プロセスのためにカーネルが割り振られる時間が含まれる。
（ｉｖ）システムの「使用可能時間」に基づいて計算される時間。これは、システムがブートしてから経過した時間を表す。

デバッガは、オペレーティング・システムがクロックに結合し、ユーザ空間プログラムへのインタフェースを提供するときに、オペレーティング・システムに時間計算のための機能を提供するよう要求する。オペレーティング・システムが、プロセスのスケジューリング、またはシステムがブートしてからの時間の追跡を担当するので、カーネルは、技術（ｉｉ）、（ｉｉｉ）および（ｉｖ）を提供することができる。

タイミング情報は、オペレーティング・システムから得る以外に、その他の技術によっても得ることができる。例えば、ハードウェアにおいては、時間が経過するとタイマがチップに信号を送る場合がある。このイベントは、実際には、デバッグ・レジスタにビットを設定して、ブレークポイントを使用可能にすることである場合がある。

上述の４種類の技術は、カーネルが提供するタイマ機能を使用する既存の技術である。このような種類の時間計算方法は、ＬＩＮＵＸなどの既存のオペレーティング・システムが使用している。その他の時間計算技術を、デバッガの必要に応じて、また、そのような技術を実施するために利用可能な機能に応じて含めることができる。

タイマは、定期タイマと「ワン・ショット」タイマの２種類が可能である。ワン・ショット・タイマは、満了したことを１度だけプロセスに知らせ、一方、定期タイマは、それを繰り返し知らせる。タイマの種類の選択は、何を実施すべきかに依存する。時間ベース・ブレークポイントの場合、経過時間、またはプロセスが消費したＣＰＵ時間、またはさらにシステムの使用可能時間に対して定期的なチェックがなされる。

デバッガが子プロセスの実行を停止させると、デバッガが再びプロセスを実行するまで、子プロセスにはタイム・スライスが割り振られない。したがって、オペレーティング・システムは、通常、子プロセスのＣＰＵ時間に基づいたアラーム・メカニズムを提供しない。アラームは、タイマが満了したときにプロセスに送られる通知である。

「ウォール・クロック」タイマにアラーム・メカニズムを設ける。このクロックは、プロセスにＣＰＵ時間が割り振られるかどうかにかかわらず、常に実行しているからである。そのため、時間計算技術が「ウォール・クロック」時間計算技術以外の場合には、時間が経過したかどうかの判断について定期的なチェックが行われる。

プログラマにさらなるフレキシビリティを提供するために、デバッガは、デバッグ操作が行われているとき、タイマを自動的に一時停止することができる。これは、プログラマが、ブレークポイントのタイマに関して経過した総時間を計算する際に、デバッグに費やした時間を含めたくない場合には非常に役に立つ機能であり得る。このような計算の精度は、実施方法が異なると異なる可能性がある。

本明細書で説明しているように、このような計算に定期タイマを使用することができる。経過時間がプロセスに割り振られているＣＰＵ時間に基づく場合にも、定期タイマが必要になることがある。なぜならば、タイマが満了したときに、カーネルはそれをデバッガに知らせないからである。このために、デバッガは、プロセスに割り振られているＣＰＵ時間を定期的にチェックする。ブレークポイント・タイマの場合の最適な解決策は、各ブレークポイントに１つのタイマを備えることである。望ましくは、このようなタイマのそれぞれが、それ自身が選択する関数を呼び出すことができる。

実際には、複数タイマには制約および負担があるため、主定期タイマを使って、すべてのブレークポイントについてその満了時間を追跡することができる。以下、このような定期タイマをデルタ・タイマと呼ぶ。デルタ・タイマは、デバッガについて時間を追跡できるように、またはその他のタイマが満了したかどうかの定期的チェックを行うことができるように、デルタ単位の時間のその単位ごとにパルスが割り振られるためである。

したがって、「ブレークポイントのタイマの開始」を、そのブレークポイントの満了時間がデルタ・タイマに登録されるように実装することができ、そのブレークポイントのための個別タイマはない。トリガは、ブレークポイントのタイマを開始させるメカニズムである。タイマが満了すると、デバッガは適切な関数を呼び出すはずである。

デバッガは、適切なデルタの値でデルタ・タイマを開始して、タイマの精度を制御する。このタイマは、デバッガの初期化時、または最初のトリガに到達したときに、設定および開始することができる。定期タイマが設定されていると、オペレーティング・システムは、そのタイマが満了した場合は必ずプロセスに通知する。同様に、デルタ・タイマの場合、デルタ単位の時間の単位が満了する都度、カーネルがデバッガに通知する。

タイマが満了したときに呼び出されるプロシージャは、ハンドラ・プロシージャと呼ばれる。ハンドラ・プロシージャは、タイマを使用しているアプリケーションが期待する機能に応じて、プログラムされている。

デバッガの場合、これは、経過した時間を計算すること、またはタイマが満了したかどうかのチェックを行うことであり得る。任意で、デルタ・タイマに、所定の間、時間の計算を停止するよう指示することができる。たとえば、プログラマが、ブレークポイントにヒットしたときにはプログラムの状態を調べたいという場合に、デルタ・タイマに停止するよう指示することができる。したがって、デルタ・タイマは、経過時間の追跡が可能になっている場合にのみ、それを行う。

デルタ・タイマの実装方法の１つは、デルタ単位の時間の単位ごとに満了する間隔タイマのための信号ハンドラを、デバッガが設置することが含まれる場合がある。このハンドラは、タイマに指定された間隔が満了したことをカーネルがデバッガに信号送信したときに呼び出される。

図６は、プログラマが単一の時間ベース・ブレークポイントを置くことを選択した場合の単純な例を略図で表したものである。子プログラムの実行の間、デバッグ中断は全く生じていないので、プログラマがその他の種類のブレークポイントを何も置かなかったこと、または、デバッガがトリガに遭遇したときに、デバッガがそのようなブレークポイントを使用不能にしていたことが想定されよう。

図６は、時間軸６１０を含む。時間Ｔ１ ６２０でトリガに到達し、プログラマは、時間Ｔ１’６２０’でプログラムが中断することを望む。タイマの満了時間はＴ秒である。すなわち、Ｔ＝Ｔ１’−Ｔ１。

単一の時間ベース・ブレークポイントがあるため、デバッガは時間がＴ１のときにデルタ・タイマを開始し、経過時間がＴ１’に到達したかどうかをチェックし続ける。このようなことが発生すると、デバッガは、子プロセスに信号を送って、子プロセスにその実行を停止するよう通知する。次いで、プログラマはプログラムの状態を調べることができる。

この単純なケースには、その他のデバッグ操作は含まれない。すべてのデバッグ操作が使用不能であり、時間ベース・ブレークポイントが１つだけに限定されるようにデバッガが設計されている場合には、単純な間隔タイマをデルタ・タイマと置き換えることができる。

間隔タイマは、トリガに遭遇すると時間の計算を開始し、タイマが満了したときにのみデバッガに通知する。デバッガは、この通知を受け取ると、子プログラムの実行を一時停止するはずである。

図７は、デバッガでプログラムが実行されている間にデバッガ操作を伴う、２つのケースを略図で表したものである。第１のケースでは、トリガに到達した時間とプログラムが中断される時間の間に１回しかデバッグ操作が行われない。

プログラマが、デバッグ中に費やした時間を無視したいという場合がある。第１のケースでは、Ｔ１ ７２０とＴ１’７２０’の間の算出された経過時間は、単純にこれらの２つの時間の差ではない。これは、当該時間が、デバッグの間に費やされた時間ＴＤ７２５も含むためである。したがって、プログラマが時間ＴＤ７２５を無視することを選択する場合は、デバッグ操作が行われている間、デルタ・タイマは停止する。このような機能は、特にＴＤ７２５がＴよりも大きい場合には望ましい。

第２のケースでは、時間ＴＤ１ ７３５およびＴＤ２ ７４０を要する２つのデバッグ・セッションが含まれている。この第２のケースは、デバッグ時間が２つに分かれ、時間軸７１０上で分散されていることを除けば、第１のケースと同じである。２回のデバッグ操作を、ＴＤ＝ＴＤ１＋ＴＤ２というように１回のデバッグ操作と置き換えてみると、２つのケースは基本的に同じである。デバッグ操作の間、デルタ・タイマが停止され、そのときのデルタ・タイマの図を描くならば、その図は、デバッグ操作が何も行われない単純なケースを示している、図６に示すものと同じような図になる。

図６および７の時間軸６１０、７１０は、タイマが計算する仮想の時間を表しているのにすぎず、経過した実際の時間を表しているわけではない。したがって、トリガに到達した時間と、プログラマがプログラムを中断させたいと思う時間の間にデバッグ操作が行われたとしても、デルタ・タイマの時間図は、デバッグ操作が全く行われなかった場合と同じになる。これは、デルタ・タイマを停止させるメカニズムがある場合に可能性がある。

消費されたＣＰＵ時間が満了時間の役割をする場合には、デバッガの制御下でプロセスが停止すると、カーネルは時間を計算しない。したがって、デバッグ操作はこの計算に影響を及ぼさない。「ウォール・クロック」タイマは、プログラマが、デバッグ操作の間、計算を停止することを望むことができるタイマである。

図８は、プログラムの実行の間の複数の時間ベース・ブレークポイントの別の例を略図で表したものである。時間軸８１０に沿って、Ｔ１ ８２０、Ｔ２ ８３０、Ｔ３ ８４０、Ｔ４ ８５０の順でトリガに遭遇している。複数の満了時間Ｔ１’８２０’、Ｔ２’８３０’、Ｔ３’８４０’、Ｔ４’８５０’について計算を行うために、デルタ・タイマは、満了時間が最も早いトリガに代わって動作する。図８では、タイマは、時間Ｔ１ ８２０に最初に第１のトリガに遭遇したときに、その満了時間を時間Ｔ１’８２０’に設定する。第２のトリガに遭遇しても、Ｔ１’８２０’はＴ２’８３０’よりも早いため、満了時間は変わらない。第３のトリガの場合、タイマは、Ｔ３’８４０’でトリガに遭遇すると、その満了時間を再調整する。これは、第３のトリガ（Ｔ３’８４０’）の満了時間が、タイマに登録されている満了時間（Ｔ１’８２０’）よりも早いためである。第４のトリガの満了時間はＴ４’８５０’であり、これは、すべての満了時間の中で最も遅い。第１の満了時間に到達すると、デバッガは適切な動作を行う。タイマは、次いで、その満了時間をＴ１’８２０’に再調整する。これは、残っている３つのトリガの満了時間の中では最も早い満了時間である。

実行が進むにつれて、満了時間は、Ｔ２’８３０’、Ｔ４’８５０’に、その順番で設定される。タイマの満了時間の変化は、Ｔ３’８４０’＜Ｔ１’８２０’＜Ｔ２’８３０’＜Ｔ４’８５０’という事実に基づいている。したがって、満了時間は、トリガに遭遇する度に再調整される。上述のように、プログラム実行が中断すると、デルタ・タイマの図は、デバッグ操作が全く存在しない場合と同じになる。これは、タイマが、それらの期間、時間を計算することを停止した場合に起こり得る。同様に、このケースでそのようなタイマを使用した場合、デルタ・タイマの時間図は、図８のようになる。

時間ベース・ブレークポイントおよびタイマの実装方法は異なることがあり、上記のケースは、記載の実装方法とは異なる場合がある。各ケースの各目的は、指定した時間が経過したときにデバッガが実行を一時停止できるようにすることである。プログラマが、デバッグ操作の間、タイマが時間を計算することを停止するように望む場合、デバッガが、タイマにいつ停止するかを通知するはずである。この通知は、ブール・フラグの設定、またはタイマのハンドラ・プロシージャの登録解除といった形態が可能であり、また、プログラマがプログラム実行を続行することを選択した場合には、このフラグを再登録するという形態が可能である。カーネルは、通常、タイマを一時停止させる機能を提供しない。しかし、カーネルがこの機能を提供する場合には、その機能をデバッガが使用することができる。

前に説明したように、タイマは、その満了時間を変更する必要がある場合がある。したがって、トリガに遭遇すると、２つのうちどちらを使用すべきかを決定するために、新しい満了時間を、現在の満了時間と比較するはずである。タイマはまた、現在の満了時間に到達したときに新しい満了時間を選択するために、ソートした満了時間一覧を維持することもできる。ある満了時間を別の満了時間と比較するとき、すべての満了時間が、共通の時間線に基づき、それと比較されるように注意がなされる。この目的で、満了時間はタイマに登録される。

下記の表７に、きわめて単純なハンドラ・プロシージャの擬似コード例を示す。

タイマを開始するために、また経過した時間を追跡するためには、トリガおよびタイマが必要である。時間が経過したときにとるべき動作を変更することによって、さまざまなタイプの時間ベース・ブレークポイントを得ることができる。プログラム実行を一時停止する代わりに、時間が経過した後、新しいブレークポイントを挿入することができる。これは、所定の間、休止状態でいる、遅延ブレークポイントの機能を提供する。デバッガは、子プログラムのスタートアップの間、またはプログラムが続行されるときに、ブレークポイントを挿入する。この発想をさらに拡張するために、トリガ／タイマ・メカニズムを使用することによって、しばらくしてから、ブレークポイントのすべてまたはいくつかを使用可能にすることができる。これによって、プログラマは、その間、すべてのブレークポイントが一時停止または非機能状態になる「非ブレークポイント時間帯」を定義することができる。実際には、デバッガが、経過時間に依存して、プログラムをデバッグしながら特定のタスクを実行する場合に、トリガ／タイマ・メカニズムを使用することができる。

コンピュータ・ハードウェアおよびソフトウェア
図９は、本明細書に記載の技術を実施するプロセスにおいて、ステップを実施するために使用することができるコンピュータ・システム９００を略図で表したものである。コンピュータ・システム９００は、説明した技術を実施する際の支援となるようにプログラムされた、コンピュータ・ソフトウェアを実行するために提供されている。このコンピュータ・ソフトウェアは、コンピュータ・システム９００上にインストールされた適切なオペレーティング・システムの下で実行する。

このコンピュータ・ソフトウェアは、コンピュータ・システム９００が解釈することができる１組のプログラムされた論理命令を含み、それらの論理命令は、それらが指定する所定の機能を実行するよう、コンピュータ・システム９００に命令するためのものである。このコンピュータ・ソフトウェアは、適合性のある情報処理システムに、特定の機能を、直接、または別の言語、コード、または記述法に変換した後、実行させることを目的とした１組の命令を含む、いずれかの言語、コードまたは記述法で記録された表現であってよい。

このコンピュータ・ソフトウェアは、適切なコンピュータ言語で書かれたステートメントを含むコンピュータ・プログラムによってプログラムされている。このコンピュータ・プログラムは、コンパイラを使って、オペレーティング・システムが実行するのに適したバイナリ・フォーマットのコンピュータ・ソフトウェアに処理される。このコンピュータ・ソフトウェアウェアは、上述の技術のプロセスにおいて特定のステップを実行する、さまざまなソフトウェア・コンポーネント、またはコード手段を含むようにプログラムされている。

コンピュータ・システム９００のコンポーネントには、コンピュータ９２０、入力装置９１０、９１５、およびビデオ・ディスプレイ９９０が含まれる。コンピュータ９２０は、プロセッサ９４０、メモリ・モジュール９５０、入出力（Ｉ／Ｏ）インタフェース９６０、９６５、ビデオ・インタフェース９４５、および記憶装置９５５を含む。

プロセッサ９４０は、オペレーティング・システム、およびオペレーティング・システムの下で実行するコンピュータ・ソフトウェアを実行する、中央処理装置（ＣＰＵ）である。メモリ・モジュール９５０は、ランダム・アクセス・メモリ（ＲＡＭ）および読取り専用メモリ（ＲＯＭ）を含み、プロセッサ９４０の指示のもとで使用される。

ビデオ・インタフェース９４５はビデオ・ディスプレイ９９０に接続され、ビデオ・ディスプレイ９９０上に表示するためのビデオ信号を供給する。コンピュータ９２０を操作するためのユーザ入力は、キーボード９１０およびマウス９１５からなる入力装置９１０、９１５から供給される。記憶装置９５５には、ディスク・ドライブまたはいずれかのその他の適切な不揮発性記憶媒体を含めることができる。

コンピュータ９２０の各コンポーネントは、データ、アドレス、および制御バスを含むバス９３０に接続されており、それによって、これらのコンポーネントは、バス９３０を介して互いに通信することができる。

コンピュータ・システム９００は、インターネットとして表されているネットワーク９８０への通信チャネル９８５を使って、入出力（Ｉ／Ｏ）インタフェース９６５を介し、１台または複数のその他の同様のコンピュータに接続することができる。

コンピュータ・ソフトウェア・プログラムは、コンピュータ・プログラム製品として提供することができ、また、携帯用記憶媒体上に記録することができる。この場合、コンピュータ・ソフトウェア・プログラムには、コンピュータ・システム９００が記憶装置９５５からアクセスすることができる。あるいは、コンピュータ・ソフトウェアに、コンピュータ９２０が、直接、ネットワーク９８０からアクセスすることができる。いずれの場合も、ユーザは、キーボード９１０およびマウス９１５を使ってコンピュータ・システム９００と対話することによって、コンピュータ９２０上で実行している、プログラムされたコンピュータ・ソフトウェアを動作させることができる。

コンピュータ・システム９００を一例として説明している。記載の技術を実施するために、コンピュータ・システムのその他の構成またはタイプも、同様にうまく使用することができる。上記は、記載の技術を実施するのに適した、特定のタイプのコンピュータ・システムの例にすぎない。

アプリケーション
プログラムによっては、比較的長時間実行された後、性能上の問題を呈するものがある。プログラマは、指定した時間に到達したときにプログラム実行が停止するように、特定の関数にブレークポイントを置きたいと考えることがある。このような状況においては、時間ベース・ブレークポイントが望ましい。

その他の場合には、製品のロジックにおけるエラーのために所定の時間が経過したときには必ずプログラムのデバッグを行う必要が生じる場合がある。例としては、実行後３時間経ってもデータを出力することができないために、デバッグの必要があるプログラムが挙げられる。時間ベース・ブレークポイントは、このような場合にも助けとなる。

別の例としては、所定の時間内には何度もヒットし、その後はヒット回数が少なくなるいずれかの関数が挙げられる。所望の効果が、低ヒット中にその関数をデバッグすることであり、高ヒットの時間帯がわかっているのであれば、低ヒット中にのみ時間ベース・ブレークポイントが効力を発するようにできる。たとえば、アプリケーションの実行開始から最初の１０秒間は、頻繁に特定のファイルにアクセスするアプリケーションについて考えてみる。この１０秒間は、アプリケーションが初期化に要する時間である。

初期化が完了した後、そのファイルへのアクセスは、頻度が少なくなり、代わりにユーザ・イベントに基づいてなされるようになる。ここで、プログラムのある「バグのある」部分が、そのファイルを誤って読み取っている可能性があり、これが、解決する必要のある調査中のバグであるとする。このバグは、アプリケーションが初期化を完了した後に存在する。このような場合、プログラマは、ブレークポイントが１０秒後にのみ効力を発するように、すなわち、アプリケーションの初期化が完了してから効力を発するように、ファイル・アクセス・ルーチン中にブレークポイントを設定することができる。ここで、ブレークポイントは１０秒の遅延後に設定され、プログラマは、初期化中にその関数で中断する必要はなく、ユーザ・イベントによってアプリケーションがファイルにアクセスするときにのみ中断すればよい。

所定の時間（Ｔ秒など）、中断されることなく（ブレークポイントによってさえも）実行されなければならないプログラムについて検討する。このような中断されない動作は、プログラムのロジックが正しく実行するためには不可欠なものであるためである。Ｔ秒間実行した後は、プログラムの実行を中断することができる。このような場合、Ｔ秒における変数の値を判断することはできないので、時間ベース・ブレークポイントを使用することが望ましい。したがって、この場合は、変数カウントなどのその他の可能なパラメータと比べて、時間が、ブレークポイントを設定するためのより適切なパラメータとなる。

記載の実施方法は、プログラマが手動で介入することなく自動的に動作し、正確であり、既存のアプローチよりもエラーが生じにくい。

さらなる変形形態
時間ベース・ブレークポイントを提供する記載の技術を、ユーザ指定の時間が経過したときにブレークポイントが満了するように拡張する。これに伴う時間の計算は、上記と同様である。このような機能は、プログラムが実行を再開した時間から開始し、所定の時間が経過した後は、ブレークポイントに到達してもそれが必要ではないとユーザが判断できる場合には望ましい。この場合、タイマは、実行が再開されるときに開始され、ブレークポイントに最初に遭遇したときには開始されない。タイマは、プログラムが実行を再開してから経過した時間を追跡し、指定した時間内にブレークポイントにヒットしなかった場合には、そのブレークポイントは使用不能になる。これによって、プログラマは、それを使ってデバッグ・セッション中にブレークポイントの必要にアクセスするパラメータとして、時間を使用することにより、ブレークポイントを使用不能にすることができる。このようなブレークポイントの使用は、デバッグしているプログラムのロジックに依存する。

たとえば、プログラムの実行再開後１０秒以内に到達するブレークポイントでなければ役に立たないとわかっている場合、プログラマは、１０秒経過後にブレークポイントを満了させることを選択することができる。タイマが満了する前にブレークポイントにヒットした場合に実行されるべき動作は、実施方法によってことなる可能性がある。たとえば、ある実施方法では、ブレークポイントにヒットした場合でも、ブレークポイントの満了に移ることを選択できる。同様に、別の実施方法では、タイマをリセットし、実行が再開すると再びそのタイマを開始することを選択できる。第３の実施方法では、指定した時間が経過する前にヒットしたブレークポイントは、いずれかの通常のブレークポイントとして扱うことを選択できる。いずれの場合も、ブレークポイントは、カウント値ではなく、時間の測定値に基づいて満了する。

上記を、監視されている時間の間、ユーザによる介入（すなわち入力）がなかった場合には実行を続行する、特別な種類のブレークポイントに拡張することもできる。たとえば、ユーザが、ブレークポイントに到達してから３秒間、どのキーも押さなかった場合には、プログラムはユーザ入力を待つのではなく続行する。この機能は、プログラムの実行を観察し、ある関数に到達したかどうかを判断するためにその関数で一時停止することを望むプログラムに対し、支援を提供することができる。タイマは、ブレークポイントにヒットしてからの時間を追跡する。プログラマがユーザ入力を行わないまま時間が経過すると、デバッガは自動的にプログラムの実行を再開する。

この種のブレークポイントによって、プログラマは、キーボード・ベースまたはマウス・ベースの入力を行うことによってデバッガに実行を続行させる必要がなくなる。

この機能は、プログラムの機能を理解するための学習ツールとしてデバッガを使用するプログラマにとって、特に役立つものである。また、このような機能によって、プログラマは、プログラムの実行について書き留めたり、クラス・チャート図を参照するなどのその他のタスク、または、必要とされるユーザ入力がプログラマにとって不便となるいずれかのその他のタスクに集中できるようになる。

結論
本明細書では、時間ベース・ブレークポイントを提供するデバッガという状況において、方法、コンピュータ・システム、およびコンピュータ・ソフトウェアを説明している。

当業者には明らかであろうが、本明細書に記載している技術および構成にはさまざまな変更および修正を加えることができる。

まとめとして、本発明の構成に関して以下の事項を開示する。

（１）コンピュータ・ソフトウェア・プログラムのデバッグの支援に適した時間ベース・ブレークポイントを使って、コンピュータ・プログラムをデバッグする方法であって、
デバッグされているコードの実行に関連付けられたブレークポイントに遭遇するステップと、
時間の測定を監視するためにタイマを起動するステップと、
前記タイマを監視して、監視されている時間が所定の長さの時間を超えたときを判断するステップと、
前記監視されている時間が前記所定の長さの時間を超えた場合に、所定の動作を実行するステップとを含む方法。
（２）前記監視されているタイマは、前記ブレークポイントに遭遇してから経過した時間を測定する、上記（１）に記載の方法。
（３）前記監視されているタイマは、前記ブレークポイントに遭遇してから、中央処理装置が関連するプロセスを実行している間に経過した時間を測定する、上記（１）に記載の方法。
（４）前記監視されているタイマは、前記ブレークポイントに遭遇してから、中央処理装置が関連するプロセス、およびオペレーティング・システムのカーネルを実行している間に経過した時間を測定する、上記（１）に記載の方法。
（５）前記所定の動作は、前記デバッグされているコードに関わる、関連するプロセスの実行を一時停止するステップを含む、上記（１）に記載の方法。
（６）前記所定の動作は、前記デバッグされているコードにさらなるブレークポイントを挿入するステップを含む、上記（１）に記載の方法。
（７）前記ブレークポイントに遭遇すると、前記デバッグされているコードに関わる、関連するプロセスの実行を一時停止するステップをさらに含む、上記（１）に記載の方法。
（８）前記所定の動作は、前記デバッグされているコードに関わる、前記一時停止されたプロセスの実行を再開するステップを含む、上記（７）に記載の方法。
（９）前記関連するプロセスの実行を一時停止するステップの後、前記一時停止された関連するプロセスの実行を再開するステップをさらに含む、上記（７）に記載の方法。
（１０）前記監視されているタイマは、前記関連するプロセスの実行が再開されてから経過した時間を測定する、上記（９）に記載の方法。
（１１）前記所定の動作は、
前記関連するプロセスの実行を再度一時停止するステップと、
前記デバッグされているコード中の前記遭遇したブレークポイントを非活動化するステップと、
前記遭遇したブレークポイントを非活動化した後、前記再度一時停止した関連するプロセスの実行を再開するステップとを含む、上記（１０）に記載の方法。
（１２）前記所定の動作は、
前記関連するプロセスの実行を再度一時停止するステップと、
前記デバッグされているコード中の前記遭遇したブレークポイントを除去するステップと、
前記遭遇したブレークポイントを非活動化した後、前記再度一時停止した関連するプロセスの実行を再開するステップとを含む、上記（１０）に記載の方法。
（１３）前記所定の動作は、前記監視されている時間内にユーザ入力を受け取らなかった場合にのみ実行される、上記（８）に記載の方法。
（１４）コンピュータ・ソフトウェア・プログラムのデバッグの支援に適した時間ベース・ブレークポイントを使って、コンピュータ・プログラムをデバッグするための、媒体上に記録されたコンピュータ・ソフトウェア・プロダクトであって、
デバッグされているコードの実行に関連付けられたブレークポイントに遭遇するためのコード手段と、
時間の測定を監視するためにタイマを起動するためのコード手段と、
前記タイマを監視して、前記監視されている時間が所定の長さの時間を超えたときを判断するためのコード手段と、
前記監視されている時間が前記所定の長さの時間を超えた場合に、所定の動作を実行するためのコード手段とを含むコンピュータ・ソフトウェア・プロダクト。
（１５）コンピュータ・ソフトウェア・プログラムのデバッグの支援に適した時間ベース・ブレークポイントを使って、コンピュータ・プログラムをデバッグするためのコンピュータ・システムであって、
デバッグされているコードの実行に関連付けられたブレークポイントに遭遇するための手段と、
時間の測定を監視するためにタイマを起動するための手段と、
前記タイマを監視して、前記監視されている時間が所定の長さの時間を超えたときを判断するための手段と、
前記監視されている時間が前記所定の長さの時間を超えた場合に、所定の動作を実行するための手段とを含むコンピュータ・システム。

メモリにおいて、プログラムの実行可能イメージ中にどのように時間ベース・ブレークポイントが挿入されるかを表すステップの流れ図である。 プログラムがデバッガで実行しているときに、プログラムの実行可能イメージ中にどのように時間ベース・ブレークポイントが挿入されるかを表す概略図である。 メモリにおいて、プログラムの実行可能イメージ中にどのようにトリガが挿入されるかを表す流れ図である。 プログラム実行中にトリガに遭遇したときに、デバッガがとるステップの流れ図である。 循環トリガの設置に伴うステップを含めて、プログラム実行中にトリガに遭遇したときに、デバッガがとるステップの流れ図である。 プログラム実行および単一の時間ベース・ブレークポイントが時間に関して示されている例の概略図である。 プログラム実行および単一の時間ベース・ブレークポイントが、複数のデバッグ操作とともに時間に関して示されている例の概略図である。 プログラム実行および複数の時間ベース・ブレークポイントが時間に関して示されている例の概略図である。 図１から８を参照して説明した技術を実施するのに適した、コンピュータ・システムの概略図である。

符号の説明

９００ コンピュータ・システム
９１０ 入力装置、キーボード
９１５ 入力装置、マウス
９２０ コンピュータ
９３０ バス
９４０ プロセッサ
９４５ ビデオ・インタフェース
９５０ メモリ・モジュール
９５５ 記憶装置
９６０ 入出力（Ｉ／Ｏ）インタフェース
９６５ 入出力（Ｉ／Ｏ）インタフェース
９８０ ネットワーク
９８５ 通信チャネル
９９０ ビデオ・ディスプレイ

Claims (11)

1. コンピュータが、コンピュータ・ソフトウェア・プログラムのデバッグの支援に適した時間ベース・ブレークポイントを使ってデバッガを実行してコンピュータ・プログラムをデバッグする方法であって、
   デバックするプログラムのコードの実行に関連付けられた第１のブレークポイントに遭遇したときに、カーネルのソフトウェアタイマを起動するステップと、
   前記タイマを監視して、中央処理装置が前記コードに関連するプロセスを実行している間に経過した時間が前記第１のブレークポイントに対応づけて予め設定された満了時間を超えたときを判断するステップと、
   前記設定された満了時間を超えた場合に、ハンドラ・プロシージャを呼び出して前記コードに関連するプロセスに対し、所定の動作を実行するよう通知するステップとを含み、
   前記第１のブレークポイントに遭遇した後に第２のブレークポイントに遭遇した場合には、前記第２のブレークポイントに対応づけられた満了時間と前記第1のブレークポイントに対応づけられた満了時間とを比較して、前記設定された満了時間をより早い満了時間に変更するステップをさらに
   含む方法。
2. 前記所定の動作は、前記デバックするプログラムのコードに関連するプロセスの実行を一時停止するステップを含む、請求項１に記載の方法。
3. 前記所定の動作は、前記デバックするプログラムのコードにさらなるブレークポイントを挿入するステップを含む、請求項１に記載の方法。
4. 前記ブレークポイントに遭遇すると、前記デバックするプログラムのコードに関連するプロセスの実行を一時停止するステップをさらに含む、請求項１に記載の方法。
5. 前記所定の動作は、前記デバックするプログラムのコードに関連する、前記一時停止されたプロセスの実行を再開するステップを含む、請求項４に記載の方法。
6. 前記関連するプロセスの実行を一時停止するステップの後、前記一時停止された関連するプロセスの実行を再開するステップをさらに含む、請求項４に記載の方法。
7. 前記監視されているタイマは、前記関連するプロセスの実行が再開されてから中央処理装置がデバックするプログラムのコードに関連するプロセスを実行している間に経過した時間を測定する、請求項６に記載の方法。
8. 前記所定の動作は、
   前記関連するプロセスの実行を再度一時停止するステップと、
   前記デバックするプログラムのコード中の前記遭遇したブレークポイントを非活動化するステップと、
   前記遭遇したブレークポイントを非活動化した後、前記再度一時停止した関連するプロセスの実行を再開するステップとを含む、請求項７に記載の方法。
9. 前記所定の動作は、
   前記関連するプロセスの実行を再度一時停止するステップと、
   前記デバックするプログラムのコード中の前記遭遇したブレークポイントを除去するステップと、
   前記遭遇したブレークポイントを非活動化した後、前記再度一時停止した関連するプロセスの実行を再開するステップとを含む、請求項７に記載の方法。
10. 前記所定の動作は、前記監視されている時間内にユーザ入力を受け取らなかった場合にのみ実行される、請求項５に記載の方法。
11. コンピュータに、請求項１〜１０のいずれか１項に記載の方法を実行させるためのコンピュータ・プログラム。

Images