JPH08179940A

JPH08179940A - コンピュータ・アプリケーション・プログラムをデバッグする方法およびコンピュータ・システム

Info

Publication number: JPH08179940A
Application number: JP7247074A
Authority: JP
Inventors: Thomas Preisler; トーマス・プレイスラー; Wayne C Gramlich; ウェイン・シイ・グラムリッチ; Eduardo Pelegri-Llopart; エドゥアルド・ペレグリ−ロパート; Terrence C Miller; テレンス・シイ・ミラー
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1994-09-01
Filing date: 1995-09-01
Publication date: 1996-07-12
Also published as: EP0699996A1; US5675803A

Abstract

(57)【要約】【課題】より融通性のあるプログラム・デバッグ手法
を提供する。【解決手段】ユーザはデバッグ・セッションを開始し
て、コード内にエラーが発見されると、ユーザがエラー
を訂正するために対応するソース・コードを編集するこ
とができ、その後デバッグ・セッションを離れることな
く「修正および継続」コマンドを実行することができる
ようにする。

Description

【発明の詳細な説明】

【０００１】関連出願本出願は、１９９４年１月２８日出願の、Ｗａｙｎｅ
Ｃ．Ｇｒａｍｌｉｃｈ、Ｓｕｎｎｙｖａｌｅ、ＣＡ、Ａ
ｃｈｕｔＲｅｄｄｙ、ＳａｎＪｏｓｅ、ＣＡ、およ
びＳｈｙａｍＤｅｓｉｒａｚｕ，ＦｏｓｔｅｒＣｉ
ｔｙ、ＣＡらによる、米国特許出願第０８／１８９０８
９号の一部継続出願である。

【０００２】

【発明の属する技術分野】本発明は、プログラム・エラ
ー・チェッキングおよび修正の分野に関する。より詳細
には、親出願はデバッガ内実行時間チェックについて開
示し、特許を請求しているが、本一部継続出願は、デバ
ッガ修正および継続システムの補助機能として機能拡張
コンパイラおよびダイナミック・リンカを使用して、エ
ラー検出および訂正を行う方法および装置に関するデバ
ッガにおける発明を開示し、特許を請求する。

【０００３】

【従来の技術】プログラムのサイズおよび複雑さが増す
につれ、より融通性が高く精巧な検査およびデバッグ・
ツールの必要性もまた増加してきている。メモリ・アク
セス関連のエラーは、プログラムの実行および開発に際
して監視し、修正しなければならない最も重大なエラー
のひとつである。現在のデバッガのもうひとつの大きな
問題点は、特にプログラムのサイズが大きくなり複雑と
なった場合に、プログラムを完全にデバッグするのに要
する時間である。プログラムの検査およびデバッグに現
在行われている方法は、デバッグを目的とする特別命令
をコンパイラに出力させるか、あるいはオブジェクト・
ファイルを事後処理するかのいずれかである。

【０００４】コンパイラを使用し、デバッグを目的とす
る特別命令を出力する手法においては、所望のパッチの
各タイプは、対応するコンパイラ・フラグによって表わ
され、適切なコードがコンパイラにより挿入される。デ
バッグを目的とする特別命令をコンパイラに出力させる
この手法には、特別命令を挿入するためにプログラムを
再コンパイルする必要があるなどの重大な欠点がある。

【０００５】オブジェクト・ファイルを事後処理する手
法では、オブジェクト・ファイルを入力として扱い、こ
れらのオブジェクト・ファイルのパッチ済みバージョン
に書き換える。実行可能プログラムのためのオブジェク
ト・ファイルがすべて変更された後、オブジェクト・フ
ァイルのパッチ済みバージョンが互いにリンクされて実
行可能プログラムを形成する。パッチおよびリンクはプ
ログラム実行以前に行われる。

【０００６】従来技術の手法の実施と使用には、さらに
他の欠点がある。ひとつの欠点は、一旦これらのファイ
ルがパッチされると、実行可能プログラムにファイルを
再リンクするための特別リンクを必要とすることであ
る。もうひとつの欠点は、パッチの動的なオン／オフ切
換ができないことである。従来技術の手法においては、
プログラム実行中にプログラムを追加パッチする場合、
パッチおよびリンクの全プロセスが必要であり、またコ
ンパイラを使用した手法の場合にはプログラムの再コン
パイルが必要になる。すなわち、追加パッチをするため
には常に、全プロセスを繰り返す必要がある。さらにも
うひとつの従来技術の手法の欠点は、共用ライブラリを
扱えないことである。プログラムと同時にロードされた
ライブラリばかりでなく、プログラムの初期ロードの後
プログラムが使用するかどうかわからないライブラリも
すべてパッチしなくてはならない。最後に、従来技術の
手法はまた、オブジェクト・ファイルおよびライブラリ
の独立したバージョンを必要とすること、ならびに従来
技術の２つの手法のパッチ範囲が機能や行をカバーする
のではなく、ファイルを扱うことしかできないというこ
とも含んでいる。

【０００７】さらに、前述の従来技術における２つの手
法はともに、静的パッチ方法を用いて、エラー・チェッ
クを受けるプログラムをパッチする。この静的パッチ方
法では、プログラムは実行前にあらかじめパッチされ、
このようなパッチは全プログラムに及び、プログラムに
対して一回だけ行われる。プログラムが直ちに使用する
ライブラリも、またプログラムが使用することのないラ
イブラリもすべて事前パッチの目的のために認識されな
くてはならない。その上、パッチ済みオブジェクト・フ
ァイルは互いに再リンクされなければならず、そのため
特別リンクが必要となってくる。

【０００８】

【発明が解決しようとする課題】以下に説明するよう
に、本発明は、従来技術の多くの欠点および限界を克服
する、より融通性のあるプログラム・デバッグ手法を提
供する。

【０００９】

【課題を解決するための手段】一旦デバッグ・セッショ
ンが開始されると、目的プログラム内で検出されたエラ
ーが迅速に訂正され、全目的プログラムがデバッグされ
るまでデバッグ・セッションが繰り返し行われるように
することが望ましい。

【００１０】たとえば、かつてはエラーが検出される
と、デバッグ・セッションは終了し、エラーがソース・
コード内で訂正され、ソース・コードが再コンパイルさ
れ、再コンパイル済みオブジェクト・コードが目的プロ
グラムの残されたモジュールに再リンクされて、すべて
が再ロードされるとデバッグ・セッションが再開されて
いた。大規模なプログラムにおいては、このプロセス
は、再リンク及びプログラムの再ロードに非常に長い時
間（何時間にも及ぶこともある）を要する可能性があ
る。このプロセスは、目的プログラムが「完全にデバッ
グされた」と判断されるまで、エラーが検出される度に
繰り返されてきた。したがって、大規模なプログラムを
デバッグするプロセスは、終了するのに非常に長い時間
がかかる可能性があった。

【００１１】かつては、エラー訂正箇所のあるファイル
のみを編集し、そのファイルのみを再ロードし、中断し
た位置からデバッグ・セッションを再開する、といった
試みがなされた。このかつての試みの問題点は、再コン
パイル操作をバイパスしようとするために、デバッガが
編集訂正事項を翻訳する必要があることだった。この手
順は、極めて遅く、関連コンパイラの維持と同時にデバ
ッガが維持されなくてはならず、デバッガが編集訂正事
項を翻訳するためにコンパイラ自体とほとんど同程度に
複雑でなければならなかった。

【００１２】本発明は「修正および継続」と称する実行
時デバッガ操作の一部である。本発明により、ユーザは
デバッグ・セッションを開始して、エラーがあった場
合、関連ソース・コードを編集しエラーを訂正してから
「修正および継続」コマンドを実行でき、しかもこれら
すべてをデバッグ・セッションを中止することなく行う
ことができる。この修正および継続コードは、コンパイ
ラを呼出して編集済みテキストを挿入したソース・コー
ド・ファイルを再コンパイルさせ、コンパイラから再コ
ンパイル済みオブジェクト・コード・ファイルを受け取
り、ダイナミック・リンカを使用し再コンパイル済みオ
ブジェクト・コードを目的アプリケーション・プログラ
ム・プロセスにリンクし、そのオブジェクト・コード・
ファイルの前のバージョンをパッチして新たに再コンパ
イル済みコードを参照し、必要な変数とレジスタをリセ
ットし、エラーが発見された時点で実行されていたコー
ドの行にプログラム・カウンタをリセットする。その後
デバッガは、デバッグ・セッションを継続し、これによ
り、通常デバッグ・セッションを中止し、目的プログラ
ムを再リンクおよび再ロードし、デバッグ・セッション
をもう一度開始するのにかかるはずの時間を節約するこ
とができる。

【００１３】この「修正および継続」の発明は、機能拡
張コンパイラを使用して、正しく関連変数をセットでき
るようコンストラクタ（constructor ）およびデストラ
クタ（deconstructor ）を処理させるためにファイルや
データを再コンパイルする方法についての情報を提供
し、レジスタを正しくリセットさせるためのデータをも
たらし、プログラムの再リンクおよび再ロードまたは全
デバッグ・セッションを再スタートする必要なく、正し
いプログラムの再スタートを行えるように静的変数をグ
ローバル化する。「修正および継続」の発明は、様々な
フラグをユーザの選択に応じてセットする融通性に富ん
でおり、コンパイラがデバッグ情報をコードに加えるよ
う命令したり、またコンパイルされるコードの行に変更
を加えることができるようになっている。

【００１４】

【発明の実施の形態】以下の詳細な説明は、主として、
コンピュータ・メモリ内のデータ・ビットに対する操作
のプロセスおよび記号表現によって表わされている。こ
れらのプロセスの説明および表現は、最も効果的にその
業務の要旨を他の当業者に伝達するために、データ処理
技術分野の当業者により使用される手段である。

【００１５】本明細書によるプロセスは、一般的にも、
望ましい結果を導く、首尾一貫した一連のステップであ
ると考えられる。これらのステップは、物理的数量の物
理的操作を要するものである。必然的にではないが、通
常は、これらの数量は記憶され、転送され、結合され、
比較されるなどの操作が可能な電気的または磁気的信号
の形態をとっている。これらの信号を、ビット、値、エ
レメント、記号、文字、用語、数字などと呼ぶことは、
主として共通慣用的な理由から、時には有用である。し
かし、これらすべての類似の用語が、適切な物理的数量
に関連するものであり、これらの数量に適用される便利
なラベルに過ぎないことに留意するべきである。

【００１６】さらに、行われる操作は、多くの場合、加
算または比較のように、操作員によりなされる知的操作
に一般に関連する用語で呼ばれている。本明細書に記載
され、本発明の一部を形成する操作のいずれにおいて
も、操作員のそのような能力は不要であり、またはほと
んどの場合望ましくはない。すなわち、操作は機械処理
である。本発明の操作を行うための有用な機械には、汎
用ディジタル・コンピュータまたはそれと類似の装置が
ある。あらゆる場合にコンピュータ操作における操作方
法と計算方法自体との間の違いを心得ておく必要があ
る。本発明は、電気的または他の（たとえば、機械的、
化学的）物理的信号を処理し他の望ましい物理的信号を
生成する際に、コンピュータを操作する方法ステップに
関する。

【００１７】本発明はまた、これらの操作を行う装置に
も関する。この装置は、必要な目的のために特別に構成
されたものでも、またコンピュータ内に格納されたコン
ピュータ・プログラムにより選択的に起動されるか再構
成される汎用コンピュータからなるものであっても良
い。本明細書に記載するプロセスは、特定のコンピュー
タまたは他の装置に、本質的に関連するものではない。
詳細にいえば、本発明の教示に従って書かれたプログラ
ムと共に様々な汎用機が使用できるし、また、必要な方
法ステップを行うために、より専門化された装置を構成
することがより便利になる場合もある。これらの機械に
必要な構造は、以下に述べる説明から明かとなろう。

【００１８】実行時チェック用動的パッチ、および迅速
な目的プログラムの訂正とデバッグ・プロセスの再開の
ための装置と方法を開示する。以下の記述においては、
説明のために、特定の命令呼出し、モジュールなどが、
本発明の完全な理解を意図して述べられる。しかし、当
業者には、これらの特定の詳説がなくとも本発明を実施
できることは明かであろう。他の例示では、本発明を不
必要に不明瞭なものにしないために、周知の回路および
装置がブロック図により示される。

【００１９】本発明は「修正および継続」のシステムお
よび方法であり、編集訂正事項を含むソース・コード・
ファイルがデバッガを離れることなく迅速に再コンパイ
ルされ、その結果生じたオブジェクト・コードおよび関
連ソース情報が既存のオブジェクト・コードに動的にリ
ンクされ、そのオブジェクト・コードが前のバージョン
のオブジェクト・コードにパッチされ、目的プログラム
全体を再リンクおよび再ロードする必要なく、前のエラ
ーの位置でデバッグ・セッションを再スタートできるよ
うにプログラム・カウンタをリセットすることができ
る。修正および継続の発明と本特許願は、１９９４年１
月２８日出願の、ＷａｙｎｅＣ．Ｇｒａｍｌｉｃｈ、
Ｓｕｎｎｙｖａｌｅ、ＣＡ、ＡｃｈｕｔＲｅｄｄｙ、
ＳａｎＪｏｓｅ、ＣＡ、およびＳｈｙａｍＤｅｓｉ
ｒａｚｕ，ＦｏｓｔｅｒＣｉｔｙ、ＣＡらによる、”
ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｆｏｒ
Ｒｕｎ−ＴｉｍｅＥｒｒｏｒＣｈｅｃｋｉｎｇＵ
ｓｉｎｇＤｙｎａｍｉｃＰａｔｃｈｉｎｇ”なる名称
の米国特許出願第０８／１８９０８９号の一部継続出願
である。親出願はデバッガされる目的アプリケーション
・プログラムに関する実行時チェックを開示し、特許を
請求しているが、本一部継続出願は、目的アプリケーシ
ョン・プログラムのデバッグのための修正および継続エ
ラー処理システムについて開示し請求する。親出願では
動的パッチを利用してコンパイラには検出されないプロ
グラム実行時のプログラム・エラーのチェックを行う。
このような実行時エラーは、プログラムをパッチするこ
とによりチェックされる。たとえば、プログラムがメモ
リにアクセスしようとするすべての位置で、プログラム
は別の位置に分岐し、そこで、アクセスしようとしてい
たメモリ・アドレスのチェックが行われる。プログラム
がアクセスしようとしているメモリ・アドレスが無効で
ある場合、エラーが記録され、またメモリ・アドレスが
有効である場合は、プログラムは実行を継続する。実際
のパッチ・プロセスは、デバッガ内で行われる。

【００２０】図１は、動的パッチを使用した実行時エラ
ー・チェック機能を備えたコンピュータ・システムを示
すシステム・ブロック図である。本発明を不明瞭なもの
にしないために、図１において、コンピュータ・システ
ムが概念的な形態で示され、コンピュータ・システムの
多くの付随的回路、装置、接続などが示されていないこ
とが理解されよう。

【００２１】図１に示されるように、目的プログラム・
イメージは、入／出装置３０４を経てデバッガ・プログ
ラム３０７に読み込まれ、プログラム３０２のメモリ内
コピー３０８を供給するため、メモリ内に記憶される。
デバッガ・プログラム３０７内の「実行時チェック」
（ＲＴＣ）モジュール３０９と呼ばれるモジュールは、
エラー・メッセージをプリントして、ユーザ・インター
フェースを扱い、またプログラム３０２のメモリ内コピ
ー３０８のパッチングを行う。

【００２２】このプログラム３０２のメモリ内コピー
は、本明細書において「インストゥルメンテッド・プロ
グラム」と呼ばれるパッチ済みプログラムに変わる。パ
ッチは、プログラム３０２のメモリ内コピー３０８に対
してのみ行われ、ディスク３０１に記憶されたオリジナ
ル・プログラム３０２に対しては行われない。したがっ
て、オリジナル・ファイル３０２が変えられることは決
してなく、実行可能プログラムに必要なファイルのリン
クも生じることはない。さらに、プログラム３０２を事
前パッチする必要はない。その代わり、チェックが開始
されると、パッチが行われる。したがって、ユーザによ
る選択は、実行前から実際の実行時まで遅延される。Ｃ
ＰＵ３０６は、デバッガ３０７のプログラム実行および
３０８でのプログラム・テストを制御する。ＣＰＵ３０
６は、実行すべき次の命令をポイントするプログラム・
カウンタ（「ＰＣ」）３１２を含んでいる。

【００２３】デバッガ・プログラム３０７は、ロード時
には指定されなかったライブラリを、実行時に動的にロ
ードすることができる。このようなライブラリのロード
は、デバッガ・プログラム３０７内で動的に行われるの
で、ＲＴＣモジュール３０９は、あらゆる呼出しをトラ
ップして、新たなライブラリをプログラムにロードする
ことができ、そのライブラリがロードされる直前のパッ
チを行うこともできる。このように、新しいライブラリ
もまたパッチされる。

【００２４】要するに、本発明では、実行前にプログラ
ムを事前パッチする必要はない。その代わり、チェック
が開始されるとパッチが行われ、これによりユーザの選
択は実際の実行時まで遅延される。さらに、プログラム
・ソース・コードに全く変更を加えず、したがって、実
行可能プログラムを作成するためにオブジェクト・ファ
イルを再リンクする必要をなくすことによって、本発明
の方式による手法では、特別リンクを使用せずにすむ。
最後に、このようなインストゥルメンテッド・プログラ
ム内に組み込まれた完全なチェック済みインストゥルメ
ンテッド・プログラムが作成されるように、既存のプロ
グラムのメモリ内コピーにパッチがなされる。

【００２５】図２を参照すると、実行時チェック用動的
パッチ方式の一般的な流れ図が示されている。メモリ・
アクセス・エラーを検出するために、スタックへのアク
セスおよびユーザ・メモリにアクセスするシステム呼出
しを含むすべてのメモリ・アクセス命令が遮断される。
このようなメモリ・アクセス命令は、命令実行を継続す
る前に、アクセスされるメモリ・アドレスの有効性に関
し検査される。

【００２６】このようなエラー・チェックのために、本
発明はチェックされる機能を逆アセンブルする。次に、
パッチを要する位置がパッチ・サイトとして識別され
る。さらに、これらのパッチ・サイトにおける元の命令
は、パッチ領域命令への分岐に置き換えられる

【００２７】図２に示されるように、ブロック１００で
パッチ・テーブルのためのスペースが割り当てられ、パ
ッチ・テーブルおよび値が初期化される。次にブロック
１１０に示されるように、エラー・チェックされるプロ
グラムは、ディスク・ファイル上にあるので、初めに読
み込まれロードされる。このようなプログラムはユーザ
によりアクセスされるので、通常部分的にロードされる
（ロード・オブジェクト）。しかし、図２に示されるス
テップを経て、デバッガは本質的にすべてのプログラム
がアクセスされるようにする。したがって、この結果、
デバッガ・プログラムがそのプロセスを終了すると、す
べてのプログラムがパッチされている。このデバッガ・
プログラムは、他のプロセスを読取りおよび書込みでき
るのでメモリ内にあるプログラム・イメージを変えるこ
とができる特殊なプロセスである。図２に記載されてい
るすべての操作は、デバッガ・プログラム内のＲＴＣモ
ジュールにより行われる。図２におけるブロック１３０
からわかるように、デバッガ・プログラムはロード・オ
ブジェクトのリストを作成する。ロード・オブジェクト
は、メモリ・アクセス命令を有するプログラム内にセグ
メント／機能を備えている。プログラムは、複数のこれ
らのロード・オブジェクトから構成されている。ロード
・オブジェクトの第一のタイプは、プログラムのメイン
ルーチンであり、これはプログラムのユーザに属する部
分である。またプログラムが使用する共用ライブラリも
あるが、これはロード・オブジェクトの第二のタイプで
ある。ロード・オブジェクトの２つのタイプは、プログ
ラム実行上必要なものである。デバッガ・プログラム
は、ロード・オブジェクトのリストを受け取ると、後に
パッチせよという命令を検索しながら、ロード・オブジ
ェクトを走査する。命令を１つ１つ走査する間、デバッ
ガ・プログラムが調べるロード・オブジェクトの一部だ
けが命令そのもの、すなわち、テキストであり、データ
ではない。

【００２８】デバッガ・プログラムは、パッチ・サイト
を識別する一方で、パッチ・サイトのアドレス、パッチ
領域のアドレス、パッチ・タイプ（たとえば、メモリ・
アクセス命令タイプ）、特定のパッチ・サイトをパッチ
すべきか、アクセスするメモリのサイズなど、これらパ
ッチ・サイトに関する情報も蓄積する。すべてのロード
・オブジェクトは、前述のパッチ・サイト情報のテーブ
ルを有しており、各パッチ・サイトに対しテーブル内の
１項目が割り当てられている。パッチ・タイプまたはパ
ッチを目的とするメモリ・アクセス命令のタイプが、エ
ラー・チェックが行われるパッチ領域の対応するセクシ
ョンのサイズを画定する。特定のパッチ・サイトに対
し、ユーザが出したチェック・コマンドまたはアンチェ
ック・コマンドは特定のパッチ・サイトをパッチすべき
かを指示する。より詳細には、チェック・コマンドは、
特定のパッチ・サイトをエラー・チェックするよう指示
し、アンチェック・コマンドは逆に、特定のパッチ・サ
イトをエラー・チェックしないよう指示する。走査の最
終段階で、デバッガ・プログラムは、見い出したパッチ
・サイトを収容するために必要となるパッチ領域のセク
ションの総サイズを得る。１つのロード・オブジェクト
に対しパッチ・サイトの識別は１度行われるだけでよ
く、これに続く実行では、パッチ領域スペースに対応す
るセクションのスペースの位置を突き止め、パッチを行
うだけでよい。パッチ領域に必要な合計サイズが記録さ
れ、パッチ領域セクション・サイズのリストが作成され
る。パッチ領域セクションサイズのリストは、次のステ
ップであるステップ１４０への入力となり、ここで、メ
モリ・スペースが実際にパッチ領域に割り振られる。ス
テップ１４０において、デバッガ・プログラムは、パッ
チ領域セクション・サイズのリストを受け取り、そのた
めのスペースを割り振ろうとする。デバッガ・プログラ
ムはまず、どこにすべてが配置されるかを知るためにア
ドレス・スペースの初期マップを作成する。システムは
メモリ内の様々な場所にあるロード・オブジェクトをマ
ップする。このようなロード・オブジェクトのマッピン
グは必ずしも連続しているとは限らず、アドレス・スペ
ースにはホールがある。デバッガ・プログラムのジョブ
はこうしたホールを識別し、これらのホールに必要なス
ペースを要求するリストをマップすることである。

【００２９】本発明の１つの実施の態様においては、各
セグメントの開始アドレスおよびサイズに加え、アドレ
ス・スペース内のすべてのセグメントのリストを取得す
るために、アドレス・スペース・データがアクセスされ
る。これらのセグメントは、テキスト、データ、スタッ
クおよび／またはヒープ・セグメントから成っている。
本明細書で「ホール」と呼ぶ、これらのセグメントの間
のスペースは、パッチ領域のセクションのためのスペー
スを割り振るのに使用される。各テキスト・セグメント
の開始アドレスおよびパッチ領域のセクションのサイズ
を含み、各テキスト・セグメントの開始アドレスの昇順
にソートされたリストは、前のステップ１３０から得ら
れる。ステップ１４０において、各ホールの開始アドレ
スによりソートされたホールの開始アドレスおよびセグ
メント・サイズを備えるホールのリストが生成される。
前述のホールは、パッチ領域の対応するセクション用パ
ッチ・サイトよりも高位のアドレス位置を有するホール
に対する最初のチェックにより必要とされるパッチ領域
のセクションのサイズと比較される。スペースが割り振
られるパッチ領域のセクションのサイズより大きいサイ
ズを有するホールが与えられ、そのホールがスタック・
セグメントの直前にない場合、パッチ領域のセクション
はホール・スペースに割り振られる。パッチ領域セクシ
ョン・サイズのリストおよびホールのリストを終了し、
パッチ領域のセクションにホールを割り振った後、生成
された割振り解除パッチ領域セクションのリストは降順
に走査される。対応するパッチ領域のセクション以上の
パッチ・サイトよりも低位アドレスにあるホールが検索
される。特定のパッチ領域のセクション以上のホール
は、そのパッチ領域のセクションに割り振られる。この
ようなパッチ領域のセクションはホールの最下部に置か
れる。対応するパッチ領域のセクションが、このステッ
プの終了時点で割り振られていないパッチ・サイトはど
れもパッチされず、ユーザにはエラー・チェック要求が
満たされていない旨の警告が出される。ステップ１５０
において、システムは、すべてのパッチ領域のセクショ
ンを発見した位置の情報を得て、その情報をパッチ・テ
ーブルに記憶し、これらのパッチ・テーブル内のアドレ
ス情報を更新する。

【００３０】ステップ１６０において、パッチ領域のセ
クション用スペースが割り振られ、パッチすべき元プロ
グラム内のすべての命令が識別される。こうして、この
時点で、パッチは実際に書き改められ、この段階の完了
時にはプログラムは完璧なインストゥルメンテッド・プ
ログラムに変えられる。前述のようにパッチ・サイト情
報を含むデータのテーブル（すなわち、パッチ・サイト
アドレス、パッチ領域アドレス、パッチ・タイプ、パッ
チ・サイトをパッチすべきか、参照されるメモリ・サイ
ズを含む）は、パッチ・サイトを決定する際使用され
る。パッチ・サイトおよび対応するパッチ領域のセクシ
ョンを含むページが読み取られていない場合、それらが
読取られ、パッチ・タイプが対応するパッチ領域のセク
ションに書き込まれる。パッチ・サイト内のオリジナル
命令は、対応するパッチ領域のセクションへの分岐命令
に置換され、このような置換済みオリジナル命令は、対
応するパッチ領域のセクションに配置される。このパッ
チングは、この特定のパッチ・サイトに対しアンチェッ
ク・コマンドが発せられない限り行われる。一方、この
特定のパッチ・サイトに対しアンチェック・コマンドが
発せられた場合、その特定のパッチ・サイトはパッチさ
れない。パッチ領域のセクションは、パッチ・サイトが
更新される前に書き込まれるので、パッチ処理中は、矛
盾状態に陥ることはない。

【００３１】ロード・オブジェクトへの割込みは、パッ
チ処理中はブロックされ、ロード・オブジェクトのパッ
チの間のサービスには、ロード・オブジェクトが正しく
パッチされるか、または全くパッチされないかを確かめ
ながら、そのブロックが解除される。プログラム稼動中
にユーザによりチェック・コマンドが発せられると、そ
の時点でスタック上でアクティブなロード・オブジェク
トのパッチは不可能になる。しかし、プログラム稼動中
に発せられたアンチェック・コマンドは、パッチを、ロ
ード・オブジェクトからアンインストールする。このス
テップは、プログラムが実行する直前に、プログラム上
で行われた最初のパッチングを終了させる。

【００３２】基本的には、ユーザがデバッガ・プログラ
ム内でプログラムを実行しようとすると、図２における
ステップ１００からステップ１６０のすべてのステップ
が、実行される。すなわち、ステップ１００ないしステ
ップ１６０は、プログラムが実行開始した時点で存在し
ていたすべてのロード・オブジェクトのパッチを終了す
る。

【００３３】さらに、デバッガ・プログラムは、プログ
ラムが実行開始した時点でプログラム内に存在しなかっ
た新しいロード・オブジェクトを、動的にロードするこ
ともできる。システムは新しいロード・オブジェクトへ
のすべての呼出しをトラップし、プログラムが新オブジ
ェクトをロードしようとしているのを知ると、デバッガ
・プログラムが同様の一連のステップを行う。ステップ
１１０、１２０、２００、１４０、１５０、１６０およ
び１７０は、新しいロード・オブジェクトの動的ロード
を示す。このステップは、初期設定がないことを除いて
は、前述でたどったステップと同一である。グローバル
初期設定は、１度だけ行われ、その後、動的にロードさ
れる新しい各ロード・オブジェクトごとに、これらのス
テップが行われる。

【００３４】ステップ１７５、１８０および１８５に示
されるように、デバッガ・プログラムはまた、パッチを
アンインストールし、ロード・オブジェクトを動的にア
ンロードすることができる。ステップ１７５において、
アンチェック操作は、セグメント、モジュール、機能ま
たは命令のいずれかのパッチのアンインストールをトリ
ガする。パッチ済み機能が与えられると、アンインスト
ールされるパッチ・サイトを含むページおよび対応する
パッチ領域のセクションを含むページが読み取られる。
次いで元の命令がパッチ領域のセクションから取得さ
れ、パッチ・サイト内のパッチ領域分岐命令は、このオ
リジナル命令によって置換される。パッチ・サイトにお
けるパッチ命令のこの置換に加え、これらのパッチ・サ
イトのユーザ・ブレイクポイントは、パッチ・サイトに
関連するブレイクポイント・データ構造内のパッチ命令
も置換する必要がある。パッチ・サイトがパッチされな
かった場合、ユーザに対し警告が発せられ、何もアンイ
ンストールされない。ユーザによりチェック・コマンド
が発せられても、ただパッチ・サイトの命令をパッチ領
域分岐命令に置換するのみである。

【００３５】ステップ１８０において、プログラマのオ
プションにより、ロード・オブジェクト用に割り振られ
たスペースを割振り解除することもできる。アドレス・
スペースを節約するために動的に割振り解除が行われ
る。膨大な数の新しいロード・オブジェクトがロードさ
れる場合、空きアドレス・スペースがなくなる可能性も
ある。もはや必要とされないモジュールがある場合に
は、このようなスペースを潜在的利用に備えて、割振り
解除することはより有益である。最後に、ステップ１９
０において、パッチ・テーブルは、パッチ領域の割振り
解除セクションに関する情報により更新される。

【００３６】図３は、本発明において使用される、実行
時エラー・チェック方法のための動的パッチを示してい
る。プログラムは複数のロード・オブジェクトから構成
され、ロード・オブジェクトは複数の関数を含んでい
る。ここで関数Ｆｏｏとして示される関数１０は１つの
例である。このような関数は、複数のメモリ・アクセス
関連の命令を有する。命令の１つは、ロード命令４０と
して示されている。実行時チェック（ＲＴＣ）モジュー
ルは、パッチされるすべてのロード・オブジェクトのた
めにこのような命令をすべてパッチする。この実行時チ
ェック（ＲＴＣ）モジュールは、図２のステップ１３０
に示されたように、パッチを要するすべての命令を１つ
１つ走査し、その後元の命令が、パッチ領域への無条件
分岐命令に置換される。パッチされる命令の位置を、
「パッチ・サイト」２０と呼ぶ。したがって、ロード・
オブジェクト内の位置にロード命令がある場合、その位
置は「パッチ・サイト」２０と呼ばれることになる。エ
ラー・チェックが行われるメモリ・ロケーションは「パ
ッチ領域」５０と呼ばれる。パッチ領域の各セクション
６０には、固有のパッチ・サイトがある。したがって、
１，０００のパッチ・サイトがあれば、１，０００のパ
ッチ領域セクションがあることになる。

【００３７】ロード・オブジェクト内で置換される各命
令には、対応するパッチ領域セクション６０への分岐命
令がある。したがって、各パッチ・サイト２０の全ロー
ド・オブジェクトに割り当てられるパッチ領域５０のカ
スタム・セクションがあり、各パッチ・サイト２０はパ
ッチ領域５０内のそれぞれのカスタム・セクションへの
分岐に置換される。これらのパッチ領域セクション６０
は、基本的にメモリ内の別の領域にあるリアル・チェッ
ク・コード７０を呼び出すためにセットアップされる複
数の命令で構成されている。このようにして、チェック
を行うパッチ領域５０から、チェック・コードが呼び出
される。知らせるべきエラーがある場合、デバッガ・プ
ログラムはエラーを知らせるが、そうでない場合は、プ
ロセスはパッチ領域５０へと戻り、それからユーザ・プ
ログラム内で実行される次の命令まで戻る。パッチされ
る命令のタイプによって、様々なパッチ領域セクション
のタイプがある。また、別個に扱わなくてはならない遅
延分岐命令のために、様々な種類のケースもある。した
がって、パッチ領域のセクションは、同一ではない。す
なわち、パッチ領域の１つのセクションは、１つの特定
のパッチのためのものである。図３は、パッチ・サイト
がパッチ領域セクションへの分岐に置換され、さらにチ
ェック・コードへの分岐に置換され、ユーザ・プログラ
ム内で実行される次の命令に戻るプロセスを示してい
る。図３における説明に変更を加えた他のケースもあ
る。たとえば、パッチされるべき命令が、遅延分岐命令
のような分岐の遅延スロット内でパッチされる場合は、
パッチ領域およびチェック・コードへの分岐の後、プロ
セスは、エラー・チェックの前に、次々と次の命令に戻
る代わりに、分岐すべきアドレス位置へと分岐しなくて
はならない。

【００３８】図７に、この動的パッチ・システムの操作
上の効果が示されているが、ここでオブジェクト・コー
ドの連続バージョンは、オブジェクト・コードの元のバ
ージョンにパッチされる。図７を参照すると、オブジェ
クト・コードの元のバージョン６０２が複数の関数６０
８、６１０、６１２を含むことが示されている。デバッ
グ・セッションが進むにしたがい、特定の関数の新しい
バージョン６０４、６０６が再コンパイルされ、元のバ
ージョン６０２にパッチされる。たとえば、コード・バ
ージョン１６０４がデバッガにロードされると、関数
１エントリー位置６１８はパッチされ改訂コード６２２
の関数１エントリー位置へ移る。同様に、前のコード・
バージョンにおけるすべての関数エントリー位置は、改
訂コード・バージョンにおいて同じ関数の対応するエン
トリー位置をポイントするようにパッチされる。好まし
い実施の態様においては、同一のコード・セクションの
連続改訂（たとえば、６０６など）は、特定のホスト・
コンピュータ・システムにおいて使用可能なメモリの限
界まで、メモリ内の前のバージョンに同時に接続するこ
とができる。また、好ましい実施の態様においては、ユ
ーザは、デバッガ内で、オリジナル・コード・バージョ
ン６０２を、最新のコード・バージョン６０６に直接パ
ッチするオプションを選ぶこともできる。メモリ制約が
ある場合、または複数のコード・バージョンに複数のポ
インタを交差させる追加オーバーヘッドがクリティカル
なタイミング問題を生じさせる場合に、まれにこのモー
ドが必要になる可能性もある。

【００３９】これらの動的ロードおよびパッチ機能を利
用する、デバッガのさらに独創的な態様を以下に説明
し、特許を請求する。

【００４０】修正および継続本明細書で説明される好ましい実施の態様における、
「修正および継続」の発明は、前述のＳＰＡＲＣｗｏｒ
ｋｓ（ＴＭ）製品バージョン３．０および３．０．１の
デバッガ部分の一部である。ＳＰＡＲＣｗｏｒｋｓ（Ｔ
Ｍ）は、本発明の譲受人である、サン・マイクロ・シス
テムズ・インコーポレーテッドの製品である。図４を参
照すると、伝統的プログラム・デバッグのシナリオ４０
０が示されている。この場合、デバッガ・プログラムが
ロードされ、目的プログラムがロードされ４０３、デバ
ッグ・セッション４０４が始まる、伝統的なターンアラ
ウンド・サイクル４０２が示されている。伝統的ターン
アラウンド・サイクル４０２においては、エラーが発見
されると、デバッガは中断し、ソース・コードはエラー
を訂正して編集され４０６、編集済みソース・コードは
デバッガの外で（通常はｍａｋｅコマンドにより）再コ
ンパイルされていた４０８。再コンパイル済みオブジェ
クト・コード・ファイルは目的プログラムの残り部分と
再リンクされ４１０、プログラムはもう一度再ロードさ
れ４０３、デバッグ・セッションは再スタートする４０
４。次のエラーが発見されると、伝統的なターンアラウ
ンド・サイクル４０２は、デバッグ処理が終了するまで
繰り返されていた。この伝統的ターンアラウンド・サイ
クル４０２はまた、図５の流れにおけて従来技術として
示されている。「修正および継続」の発明（図４の４１
２）により、ユーザは、目的アプリケーション・プログ
ラムの実行およびデバッグを行いながら、ソース・ファ
イル４０６に変更を加え、デバッガを離れることなくソ
ース・コード・ファイル４０８を再コンパイルし、デバ
ッグ・セッション内のエラーが発見された位置４１４か
らプログラムの実行を継続することができる。本発明を
使用すると、ユーザには、１）プログラムを再リンクす
る４１０必要がなく、２）デバッガにプログラムを再ロ
ードする４０３必要がなく、３）最後のエラーが発見さ
れた位置からデバッグ・セッションを再実行する４１４
ことができる、といった利点がもたらされる。

【００４１】本発明の利用法修正および継続の発明の利用方法については、本明細書
にＡｐｐｅｎｄｉｘＡとして添付され、本明細書の一部
となる、”ＤｅｂｕｇｇｉｎｇａＰｒｏｇｒａｍ”
と題する、ＳＰＡＲＣｗｏｒｋｓマニュアルのＰａｒｔ
＃８０１−５１０６−１０、ＲｅｖｉｓｉｏｎＡＤ
ｅｃｅｍｂｅｒ１９９３、２０−２３５ないし２０−
２４０ページに記載されている。

【００４２】本発明の過程本「修正および継続」の発明による、好ましい実施の態
様の操作および構成について以下で総括的に説明する。
当業者には、いかなるプログラミング言語、いかなる同
等の動的ローダを使用しても、本発明の操作を行うプラ
ットフォームとしていかなるコンピュータを使用して
も、また基本的修理および継続操作を実行するための様
々な一連の操作を行っても、本発明を実施できることが
理解されよう。動的ローダおよびリンカは、様々なコン
ピュータおよび／またはオペレーティング・システムの
テキストで説明されている。図６にＦｉｘコマンド５０
０の基本的操作が示されている。デバッグの実にエラー
が発見されると、ソース・コードはエラーを訂正するた
めに編集され、ソース・コードに加えられた修正を記憶
した後、本発明によるＦＩＸコマンドが５０２で実行さ
れる。これに応じて、デバッガ・プログラムはコンパイ
ラを呼出し５０４、ここで訂正済みソース・コード・フ
ァイルが再コンパイルされ、共用オブジェクト（ .ｓ
ｏ）ファイルが作成される５０６。編集済みソース・フ
ァイルから生成された新たなオブジェクト・コード・フ
ァイルが、実行時リンカを使用して実行中の目的プログ
ラムに、動的にリンクされる５０８。旧バージョンのオ
ブジェクト・コードは、新たにリンクされたコードと比
較され５１０、スタック上の関数内のローカル変数に追
加、削除があったか、またはタイプに変更が加えられた
かを判定する５１２。スタック上の関数内の変数に変更
があった場合５１４、ユーザに対しエラー・メッセージ
が発せられ５１６、スタックからその関数を除去するた
めにＰＯＰコマンドを実行することを知らせ、Ｆｉｘコ
マンドは５１８で終了する。この場合、ユーザは、ＰＯ
Ｐコマンドを実行し（以下に詳細に説明する）その後Ｆ
ｉｘコマンドを再実行することになる。ローカル変数に
変更がみられない場合５２０、旧バージョンのオブジェ
クト・コードは新しいコードにパッチされる５２２。
（このパッチされたコードの構成は図７に示されてお
り、以下で詳細に説明される）。その後、プログラム・
カウンタがリセットされ５２４、旧バージョンのオブジ
ェクト・コード・ファイル内で設定されていたすべての
ブレークポイントは、新しいオブジェクト・コード・フ
ァイルに移され５２６、エラーが前回発見された位置
で、デバッグ・セッションを再開することができる５３
０。

【００４３】本発明の本質的な態様は、再コンパイル済
みファイルが目的プログラム・プロセスに再リンクされ
た後にデバッグ・セッションを継続するため、プログラ
ム・カウンタを正確にリセットできる（図６の５２４）
ことである。プログラム・カウンタは、ＣＰＵが実行す
る次の命令のアドレスを指定する。このアドレスは、何
らかのシステムにおける実メモリ・アドレスでも、仮想
メモリを含むシステムにおける仮想アドレスであっても
よい。エラーが発見された時点におけるプログラム・カ
ウンタの値は、記憶され、修正および継続操作が、エラ
ー訂正後どの位置からデバッグ・セッションを再開する
か判断できるようになっている。したがって、修正およ
び継続システムが、デバッグ・セッションを継続するよ
うユーザに制御権を戻すと、エラーが発見されて前のセ
ッションが中止した位置と本質的に同一の位置において
セットされたプログラム・カウンタを離れなくてはなら
ない。プログラム・カウンタは、エラーが起こった前の
関数のソース・コード内の行と同じ、関数の編集済みバ
ージョン内のソース・コードの行の初めに対応するオブ
ジェクト・コード位置にリセットされるが、これはその
行を含む関数が、修正されるスタックの最上位にある場
合である。しかし、プログラムがエラーのために中止し
た同じ行を含む関数が、修正されるスタックの最上位に
ない場合は、Ｐｏｐコマンドが実行できる（これは以下
で詳細に説明する）が、これにより、スタックからポッ
プオフした関数への（すなわち、エラーが検出された時
点で実行されていた関数への）呼出しを行ったソース・
コード文の始めに対応する位置を含むように、効果的に
プログラム・カウンタをセットできる。前述のＦｉｘコ
マンドについての説明で示されるように（図６参照）、
本発明の好ましい実施の態様は、スタック上の関数内ロ
ーカル変数に変更がない場合は、自動的にはＰＯＰコマ
ンドを実施しない。しかし、当業者には、これを行うこ
とが容易であることが理解されよう。

【００４４】プログラム・カウンタの調整については、
触れておく必要のある基本的な問題が２つある。１）オブジェクト指向（Ｃ＋＋など）コンストラクタお
よびデストラクタ２）浮動小数点レジスタ・スピル

【００４５】コンストラクタおよびデストラクタＣ＋＋システムにおいては、ほとんどのオブジェクト・
クラスは、少なくとも１つの「コンストラクタ」を備え
ている。これは、そのクラスのオブジェクトが作成され
ると、暗黙で呼び出される関数である。これは、オブジ
ェクトの初期値を設定する。また、「デストラクタ」と
呼ばれる、これに対応するクリーンアップ関数もあり、
これはオブジェクトが破壊される（範囲をはずれる、ま
たはヒープに戻る）時、呼び出される。デストラクタ
は、コンストラクタほど一般的ではなく、特殊終了のニ
ーズ、不要部分の整理などを処理する。デストラクタを
適切な範囲から出ると常に同期ロックが確実に解除する
完璧な手段として使用している人々もいる。したがっ
て、デストラクタは、オブジェクトに加え、オブジェク
トにかかるロックもクリーンアップする。コンストラク
タおよびデストラクタは、どのオブジェクト思考ソフト
ウェア・コンストラクション・テキストの中でも説明さ
れている。たとえば、ＢｅｒｔｒａｎｄＭｅｙｅｒ
著”Ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄＳｏｆｔｗａｒ
ｅＣｏｎｓｔｒｕｃｔｉｏｎ”、Ｐｒｅｎｔｉｃｅ
Ｈａｌｌ１９８８、ＩＳＢＮ０−１３−６２９０４９
−３を参照されたい。

【００４６】以下のコードを考察してみる。

【００４７】変数「ｆ」への代入により、コンストラク
トおよびデストラクトされる複数の「Ｐｏｉｎｔ」の一
時インスタンス化を生じさせる。拡張コードは以下のよ
うなものになるであろう。／／この位置を「Ｘ」と呼ぶ Point temp1; ／／ここではコンストラクタは呼び出されていない if(foo()){ temp1=b; ／／ｔｅｍｐ１がコンストラクタをコピー }else{ Point temp2=d.add(e); ／／ｔｅｍｐ２がコンストラクタをコピー／／この位置を「Ｙ」と呼ぶ temp1=c.add(temp2); ／／ｔｅｍｐ１がコンストラクタをコピー／／ｔｅｍｐ２デストラクタが呼び出される } Point f=a.add(temp1); ／／ｔｅｍｐ１デストラクタ呼出される

【００４８】このコードにおいて、デバッガがプログラ
ム・カウンタを位置「Ｙ」から「Ｘ」に戻す必要がある
場合（たとえば、ｃ.ａｄｄの呼出しがポップされ
る）、ｔｅｍｐ２のデストラクタが呼び出されなくては
ならない。これは、デバッガに「ｔｅｍｐ１」および
「ｔｅｍｐ２」の適切なデストラクタ・コードを呼び出
すことにより行うことができる。さらに、ユーザが、プ
ログラム・カウンタを「Ｘ」から先の「Ｙ」に進めよう
とする場合には、適切に構成されないオブジェクトもあ
る（ｔｅｍｐ１およびｔｅｍｐ２）ということがユーザ
に通知されなくてはならない。したがって、効果的な修
正及び継続デバッグ・ルーチンのためには、目的プログ
ラムを前にエラーの発見された位置に近い有意の開始位
置に正しく再調整するデストラクタの知識を備え利用す
ることができなければならない。

【００４９】次にとりあげるのは、デストラクタ・ツリ
ーの概念である。Ｃ＋＋コードのいかなる所与の位置に
おいても、Ｃ＋＋コンパイラには、デストラクトするオ
ブジェクトおよびその順序が解っている。オブジェクト
の同じセットを同じ順序でコンパイルさせるすべての位
置が、デストラクタ・ステートであるとみなされる。コ
ンパイラは、これらの各デストラクタ・ステートにゼロ
から始まる固有の数を割り当てることができる。デスト
ラクタ・ステートはツリー状に配置することができ、こ
こで各アークは１つのオブジェクトを破壊し、他のデス
トラクタ・ステートに制御を渡す。このデストラクタ・
ツリーを現デストラクタ・ステートからルートまでたど
って、すべての破壊すべき構成オブジェクトを正しい順
序で破壊する。

【００５０】図１０ａを参照すると、コンストラクタお
よびデストラクタ８００を生成するサンプル関数が示さ
れている。示されているのは、ＡがＣ＋＋クラスである
Ｃ＋＋関数である。左列８０２は行番号を示し、右列８
０４は各ソース・コード行の初めに関連するデストラク
タ・ステートを示す。図１０ｂは、関数８００に対応す
るデストラクタ・ツリー８５０を示す。デストラクタ・
ツリーのルート８５１の下では、第１ノード８５２がオ
ブジェクト「ａ」に関する第１デストラクタを参照し、
コンパイラにオブジェクト「ａ」を破壊させるすべての
位置をポイントする「２」のデストラクタ・ステートを
有している。オブジェクト「ｂ」のコンストラクタは、
関数内のオブジェクト「ａ」の後、しかもオブジェクト
「ａ」のデストラクタが実行される前に作成され、オブ
ジェクト「ｃ」のコンストラクタは、関数内のオブジェ
クト「ｂ」の後、しかもオブジェクト「ａ」のデストラ
クタが実行される前に作成される。したがって、デスト
ラクタ・ツリーは、「ｃ」のデストラクタを表わすノー
ド８５６にリンクされる、オブジェクト「ｂ」のデスト
ラクタを表わすノード８５４にリンクされる、「ａ」の
デストラクタを表わすノード８５２を有している。関数
８００において、オブジェクト「ｂ」および「ｃ」は、
オブジェクト「ｄ」が作成される時点ではすでに破壊さ
れてしまっているので、ツリー８５０内でオブジェクト
「ｄ」のデストラクタを表わすノード８５８は、オブジ
ェクト「ａ」のデストラクタを表わすノード８５２に直
接接続されている。ここで図１０ａおよび１０ｂの両図
を参照すると、プログラム・カウンタが行１４８０８
から行１０８０６に移動した場合、デストラクタ・ス
テートは、４８１４から２８１２へと変わり、ツリ
ーにしたがうと、ノード８５６におけるステート＝４の
オブジェクト「ｃ」、次にノード８５４におけるステー
ト＝３のオブジェクト「ｂ」が破壊されることになる。
同様に、プログラム・カウンタが行１９８１０から行
１０８０６にリセットされる場合、ノード８５８にお
けるステートは、オブジェクト「ｄ」が破壊されること
を示している。

【００５１】デバッガがプログラム・カウンタを１つの
位置から他の位置へと移動させようとする場合、新旧プ
ログラム・カウンタ位置に関連するデストラクタ・ステ
ートを判定し、デストラクタ・ツリー内を旧ステートか
ら新ステートへとアークを横切ることができる。各アー
ク横断がツリーのルートに向かう限り、正しいオブジェ
クトがデストラクトされる。ツリーのルートをそれたア
ークの横断がある場合、適切に構成されないオブジェク
トがあることを知らせるエラー警告メッセージが発せら
れる。

【００５２】デバッガは、比較的安全にプログラム・カ
ウンタを動かすことができるように、デストラクタ・ツ
リーにアクセスする必要がある。このデータは、コンパ
イラによりデバッガに供給されなくてはならない。コン
パイラは通常、対応するソース・コードの属性を対応す
るオブジェクト・コードと関連づけるこのようなデータ
を供給する。好ましい実施の態様においては、コンパイ
ラからのこのようなデータは、「記号表エントリ・デー
タ」または「スタブ」の形態で供給される。

【００５３】スタブ：スタブは、この種の情報を伝達す
る、受け入れられている手段である。この情報をプログ
ラムのテキスト内に埋めこむといった他の案を代用する
こともできるが、これ以上に良い解決法は見出されてい
ない。

【００５４】Ｎ＿ＳＬＩＮＥスタブを、現在行のデスト
ラクタ・ステートを含むために増加させなければならな
い。さらに、各デストラクタ・ステートは、以下の事項
を指定しなければならない。 −デストラクタ・ステート番号 −コンストラクタ後続のアドレス −デストラクタ・コードの第一命令のアドレス −実行するデストラクタ・コードのバイト数 −親デストラクタ・ステートのデストラクタ・ステート
番号

【００５５】いかにしてこれらすべてがスタブ内に符号
化されるかを、以下で説明する。オブジェクトの様々な
再初期設定およびクリーンアップを行う必要があること
に加え、ステートを再初期設定しなければならない他の
変数もある。これらについては、「未初期設定値」の項
で総括的に説明する。

【００５６】未初期設定値ＣおよびＣ＋＋ともに変数を有する。プログラム・カウ
ンタが、最初に変数に値を代入するコードを経て、１つ
進められると、値は未初期設定になりそこへの後続のア
クセスはランダム値を得る。望ましい動作は、プログラ
ム・カウンタが変数初期設定より進んで調整される度に
ユーザに知らせることである。現在好ましい実施の態様
においては、本発明はこの条件を無視する。しかし、当
業者には、代替実施が可能であることが理解されよう。
究極のインターフェースは、未初期設定される変数のリ
ストを提供することであろうが、最低限容認可能な解決
法は、少なくとも１つの変数が未初期設定される度にた
だユーザに警告を発することであろう。この動作は、変
数が最初に代入される度に増加されるカウンタを、コン
パイラに維持させることにより実施することができる。
このカウンタ値をＮ＿ＳＬＩＮＥスタブに符号化するこ
とにより、デバッガは、カウンタ値が１つの行から他へ
替わる度に警告メッセージを発することができるであろ
う。

【００５７】情報のＮ＿ＳＬＩＮＥｓｔａｂにおける符
号化Ｎ＿ＳＬＩＮＥスタブカウンタを符号化する基本的方法
は、Ｎ＿ＳＬＩＮＥスタブの「他の」８ビット・フィー
ルドにおいてデルタ符号化を使用することである。デル
タ符号化とは、そのエントリーの実値および前のエント
リーの実値の間の差だけを使用することである。コンパ
イラがこれらの値を生成する。 .ｓｔａｂｓおよび .ｓ
ｔａｂｎには、実行時コンパイラ内に生成されるアセン
プラ擬似演算コードは、以下のように画定される。 .stabs "string",type,other,desc,value .stabn "type,other,desc,value

【００５８】好ましい実施の態様において、「他の」フ
ィールドの符号化とは、２つの４ビット符号付き値に分
けることである。カウンタ値を計算するために、２つの
仮想カウンタがゼロに初期設定され、関数スタブの後の
最初のＮ＿ＳＬＩＮＥスタブから始め、４ビット符号拡
張値を使用して２つのカウンタが増加および／または減
少される。ロー４ビット・フィールドはデストラクタ・
カウンタ用に使用され、ハイ４ビット・フィールドは変
数カウンタ用に使用される。特定のスタブのカウンタ値
は、４ビット値が加えられた後に取られる。最後に、４
ビット・フィールドのいずれかがデルタ値を含むには大
きさが十分でない場合、全「他の」フィールドは２５５
に設定され、２つのデルタ値はスタブ・ストリング内で
コロンにより分離された２つの数として、符号化され
る。以下の例は、この概念を示すものである。 stabs "main:F(0,4)",0x24,0,0,_main !Vars:0 Destructs:0 .stabn 0104,0,15,LL1 !Vars:0 Destructs:0 .stabn 0104,1,16,LL2 !Vars:0 Destructs:1 .stabn 0104,16,17,LL3 !Vars:1 Destructs:1 .stabn 0104,0,18,LL4 !Vars:1 Destructs:1 .stabn "-1:-1",0104,255,15,LL5 !Vars:0 Destructs:0

【００５９】新Ｎ・コンストラクト・スタブおよび新Ｎ
・デストラクト・スタブ最終的にはデストラクトを要するオブジェクトをコンス
トラクトする度に、２つの新たなスタブがコンパイラに
よって作成される。Ｎ＿ＣＯＮＳＴＲＵＣＴスタブは、
以下のようになる。 .stabs "<variable>:<state>",N_CONSTRUCT,0,<end>-<s
tart>,<start>-<func> ここで＜ｖａｒｉａｂｌｅ＞は、オブジェクト変数名で
ある。これは、変数名がない場合空である。＜ｓｔａｔ
ｅ＞はデストラクタ・ステート番号である。＜ｓｔａｒ
ｔ＞はデストラクタ・コードの最初の命令のアドレスで
ある。＜ｅｎｄ＞はデストラクタ・コードの最後の命令
に続く命令のアドレスである。このようにして、＜ｅｎ
ｄ＞−＜ｓｔａｒｔ＞が、デストラクタ・コードのバイ
ト数を指定する。これを符号化するのには、１６ビット
は十分なスペースであるとされている。＜ｆｕｎｃ＞は
関数名である。したがって、＜ｌｏｃａｔｉｏｎ＞−＜
ｆｕｎｃ＞は、関数相対オフセットである。

【００６０】Ｎ＿ＤＥＳＴＲＵＣＴスタブは、以下のよ
うになる。 .stabs"<state>:<parent>"N_DESTRUCT,0,<end>-<start
>,<start>-<func> ここで、＜ｓｔａｔｅ＞はデストラクタ・ステート番号
である。＜ｐａｒｅｎｔ＞は親デストラクタ・ステート
番号である。０は、デストラクタ・ツリーのルートであ
る。＜ｓｔａｒｔ＞はデストラクタ・コードの最初の命
令のアドレスである。＜ｅｎｄ＞はデストラクタ・コー
ドの最後の命令に続く命令のアドレスである。したがっ
て、＜ｅｎｄ＞−＜ｓｔａｒｔ＞は、デストラクタ・コ
ードのバイト数を指定する。１６ビットは、これを符号
化するのに十分なスペースであるとされている。＜ｆｕ
ｎｃ＞は関数名である。したがって、＜ｓｔａｒｔ＞−
＜ｆｕｎｃ＞は関数相対オフセットである。

【００６１】好ましい実施の態様においては、アセンブ
ラおよび／またはコード・ジェネレータがスタブ指令の
最後の引数から２番目の式を受け入れない場合は、その
ように修正されなくてはならない。

【００６２】浮動小数点レジスタスピル／アンスピルＣおよびＣ＋＋においては、変数が「レジスタ」キーワ
ードを介してレジスタに記憶されるように指定すること
ができる。「レジスタ」指定子は、最適化されたコード
および最適化されていないコード（たとえば、−ｇ）に
おいても作動する。さらに、レジスタ指定子は、整数お
よび浮動小数点レジスタの両方にも動作する。ＳＰＡＲ
Ｃアーキテクチャは３２の整数レジスタおよび３２の浮
動小数点レジスタを備えており、整数レジスタはレジス
タ・ウィンドウ機構を介して管理されるが、浮動小数点
レジスタはそうではない。最終的に、ＳＰＡＲＣＡＢＩ
は、整数レジスタが呼出し先により保管／復元され、浮
動小数点レジスタが呼出し元により保管／復元されると
いう点においては、非対称的である。浮動小数点変数の
レジスタに記憶された変数を有する最適化されていない
コードにおいては、スピルし、各ルーチン呼出しで適切
な浮動小数点レジスタを復元するコードがある。

【００６３】たとえば、以下のコードがある。

【００６４】「ｓｐｉｌｌｄ」は「ｓｔｄ」の疑似命令
コードであることに留意されたい。さらに、「ｓｐｉｌ
ｌｄ」命令は、同時に２つの浮動小数点レジスタを節約
することに留意されたい。

【００６５】レジスタの浮動小数点変数の問題点は、プ
ログラム・カウンタが安全に動く前に「ｐｏｐ」コマン
ドが正しくその値を復元しなくてはならないことであ
る。「ｐｏｐ」コマンドは、「ｒｅｓｔｏｒｅ」命令が
起こるよう強制することにより整数レジスタを復元す
る。「ｐｏｐ」コマンドはまた、呼出し命令の遅延スロ
ットに続く命令をさがし、すべての％ｓｐ相対ロード命
令を実行する。

【００６６】Ｎ＿ＣＭＤＬＩＮＥスタブソース・ファイルを再コンパイルする操作に入ると、デ
バッガは、Ｎ＿ＣＭＤＬＩＮＥスタブの内容を実行する
だけである。コマンド行スタブの内容は、次の通りであ
る。 stabs"<cwd>;<driver><options><prefix_magic>",N_CMD
LINE,0,0 ここで、Ｎ＿ＣＭＤＬＩＮＥは０ｘ３４である。＜ｃｍ
ｄ＞はドライバからの−ｃｗｄオプションにより指定さ
れた現行作業ディレクトリである。＜ｄｒｉｖｅｒ＞は
ドライバへの全パスである。＜ｏｐｔｉｏｎ＞はコンパ
イラに渡されるオプションのリストである。このリスト
は、コンパイルされるソース・ファイルだけが指定され
るように、また .ｏファイルを生成する−ｃオプション
を指定するように変更することができる。＜ｐｒｅｆｉ
ｘ＿ｍａｇｉｃ＞はドライバを介して現行大域接頭部を
フロント・エンドに戻す一式のオプション型式である。
以下の例を参照されたい。重複修正および継続の実行に
より＜ｐｒｅｆｉｘ＿ｍａｇｉｃ＞を重複しないよう配
慮がなされていることに留意されたい。

【００６７】他の場合には／ｂｉｎ／ｓｈによって解釈
される奇妙な文字は、バックスラッシュで囲む必要があ
る。ドル符号（＄）は、このような文字の１つである。

【００６８】たとえば、「ｍｙｆｉｌｅ.ｃｃ」が次の
ようにコンパイルされた場合、ＣＣ−Ｉ./include-g-o myprog myfile.cc Ｎ＿ＣＭＤＬＩＮＥのコマンドは次のようになろう。 "<path1>;<path2>/CC-I./include-g myfile.cc-c-Qopti
on ccfe-prefix−Qoption ccfe<prefix>" ここで、＜ｐａｔｈ１＞はファイルが当初コンパイルさ
れた作業ディレクトリへの絶対パスである。＜ｐａｔｈ
２＞はコンパイラ・ドライバへの絶対パスである。＜ｐ
ｒｅｆｉｘ＞はこのファイルのコンパイルに使用された
大域接頭部である。

【００６９】大域化好ましい実施の態様において、修正および継続により再
コンパイルされる関数が、実行可能ファイル内の現行値
にアクセスできるようにするために、すべてのファイル
の静的変数を大域値に変換しなければならない。この規
則の例外は、関数内にネストされた静的変数であり、そ
れに代わり、修正サイクル中にコンパイルされると、警
告メッセージを発しなくてはならない。コンパイル操作
中に−ｇオプションが割込み可能になると、大域化が可
能になる。

【００７０】ファイルが、初めてコンパイルされると、
コンパイラは、固有の接頭部を作成し、各ファイルの静
的変数の前に付加する。固有の記号は、インターネット
・アドレス（または０）、時刻、およびプロセスＩＤ
（１６ビットのみ）で構成されている。大域接頭部は、
次の形式でＮ＿ＯＰＴスタブに符号化される。 G=<prefix>. 大域接頭部は次の形式である。 .<internet_address><time_of_day><process_id>.

【００７１】１４文字として、８０ビットが符号化さ
れ、各文字は６ビットの情報を含んでいる。ａ−ｚ，Ａ
−Ｚ，０−９，＿，＄は、６ビットを記憶するのに使用
される。以下のルーチンを、大域接頭部を得るために使
用することができる。

【００７２】以下のコードは、様々な静的変数がいかに
大域化されるかを示している。 int a; /*a static int b; /*<prefix>.b*/ foo(void) { static int e; /*<prefix>.foo.e*/ { static int f; /*修正中であれば、警告メッセージ*/ } }

【００７３】Ｃ＋＋の場合、大域化名における関数名は
意味をなさない。上記の警告メッセージは、静的変数が
再初期設定されることをユーザに知らせている。

【００７４】関数埋込み好ましい実施の態様では、本発明を含むデバッガ・シス
テムにおける修正および継続処理をサポートするため
に、すべての関数は前に４ワード付加されなくてはなら
ない。これらの４ワードは、新たにロードされたコード
へ分岐するコード・シーケンスとともにロードされる。
Ｎエントリー・ポイントのＦＯＲＴＲＡＮ関数では、埋
込み領域はＮ＊４ワードになる。−ｇが指定されるかに
はかかわりなく、埋込みはコンパイラによって行われ
る。

【００７５】埋込みはスタブ・バージョン番号に暗黙的
なので、デバッガにＮ＿ＯＰＴを介する埋込みについて
知らせる必要はない。埋込みがない場合は、デバッガは
コード・パッチのための関数の最初の４ワードを使用す
るが、関数が４ワードより少ない場合、デバッガによっ
て修正することはできず、警告メッセージが発せられ
る。

【００７６】プログラム・カウンタの設定コンストラクタとデストラクタ、静的変数、およびレジ
スタ・スピルに関する必要な情報をデバッガに伝達す
る、実行時コンパイラのための、好ましい実施の態様に
おいて使用される手法について述べてきたが、ここで、
プログラム・カウンタを設定する動作について説明す
る。図８を参照し、プログラム・カウンタ（”ＰＣ”）
リセット・プログラム７００を説明する。プログラムへ
のエントリー７０２に際し、旧ＰＣ値（プログラムを中
止させたアプリケーション・プログラム・エラーが起こ
った時点でセーブされた値）が、取り出される７０４。
この旧ＰＣ値は、旧関数コードの最初の命令をポイント
するかどうかテストされる７０６。そうであれば７０
８、ＰＣは、対応する新しい関数コードの最初の命令に
設定され７１０、７２６に戻る。そうでない場合７１
２、旧関数コードがデバッグ情報を含むかどうかがチェ
ックされる７１６。そうであれば７２２、この行をリセ
ットするデストラクタを呼び出すためにデストラクタ・
ツリーがチェックされ７１４、ＰＣが新しい関数コード
内の同じ相対行を指すように設定される７２４、７２６
に戻る。そうでない場合７１８、ＰＣは、新しい関数コ
ードの第１行の最初を指すように設定され７２０、７２
６に戻る。

【００７７】ＰＯＰコマンドの実行上述のように（図６の５１２、５１４および５１６を参
照）、Ｆｉｘコマンド・ルーチンは、スタック上の関数
内のローカル変数のいずれかに変更を検出した場合、エ
ラー・メッセージを出して終了する。このエラー・メッ
セージは、ユーザが、「ＰＯＰ」コマンドを実行し、変
更されたローカル変数を含む関数をスタックから「ポッ
プ」することをすすめている。ここで、「ＰＯＰ」プロ
グラム９００を図９を参照して説明する。

【００７８】エントリーに際して、「ＰＯＰ」ルーチン
は目的フレームをみつけ９０２、目的ルーチンがフレー
ム・ライン・デバッグ情報を有するかどうかをチェック
する９０４。そうでない場合は９０６、「ＰＯＰ」ルー
チンは放棄され９０８、９１０に戻る。そうである場合
は９１２、ルーチンは、このフレームに現行ＰＣ、現行
関数および現在行を取得する９１４。ＰＣは、この関数
のデストラクタ・ステートにマップされ９１６、フレー
ムはこれが目的フレームであるかどうかをテストする９
１８。そうでない場合９２０、ルーチンは、ステップ９
１６で見いだしたデストラクタ・ステートからデストラ
クタ・ツリーのルートまでのすべてのオブジェクトをデ
ストラクトし９２２、次のフレームに進み９２４、ステ
ップ９１４に戻って、今説明したプロセスを次のフレー
ムのために実行する。ステップ９１８において、フレー
ムが目的フレーム９２６であると判定された場合、ルー
チンは、現在行の最初のアドレスを取得し９２８、その
アドレスをこの関数のデストラクタ・ステートにマップ
し９３０、ステップ９３０で得られたデストラクタ・ス
テートから、ステップ９１６で得られたデストラクタ・
ステートに至るすべてのオブジェクトをデストラクトす
る。ルーチンはその後、浮動小数点レジスタ・スピリン
グをチェックし９３４、必要なリセットを行って９１０
に戻る。この説明において、「ｓｔａｒｔｆｒａｍ
ｅ」はプログラムが中止したスタック・フレームのこと
である。目的フレームは、スタックをポップしようとす
るスタック・フレームのことであり、この目的フレーム
は、スタック内の第二フレームであっても、またはスタ
ック内の数個下位のフレームであってもよい。

【００７９】コード・パッチングまた、前述のように（図６の５２２を参照）、旧コード
は、新たにコンパイル済みコードにパッチされる。この
パッチ・プロセス６００を、ここで図７を参照して説明
する。関数１６０８、関数２６１０および関数３
６１２を含む目的プログラムのオブジェクト・コードの
元のバージョン６０２が示されている。また、最初の修
正（すなわち、編集、再コンパイルおよび再リンク）の
結果生じたプログラムのオブジェクト・コード・バージ
ョン１６０４も示されている。このバージョン１のコ
ード・セットには、元のバージョン６０２にはなかった
関数４６２８が含まれている。また、関数３６１２
が消去された、バージョン”ｎ”（ここで”ｎ”は使用
可能なメモリによってのみ制限される任意の数でよい）
６０６のコードも示されている。ここで、コード・パッ
チング構造は、十分に柔軟性に富んでおり、特定のＦｉ
ｘサイクルが、必要に応じて新たな関数を加えたり、旧
関数を削除したりできることが示されている。旧バージ
ョンをより新しいバージョンにパッチする時、各関数の
エントリー位置は、新しい関数のエントリー位置をポイ
ントするようにパッチされる。たとえば、図７におい
て、元のバージョンの関数１のエントリー位置６１８
は、コードの次のバージョンの関数１エントリー位置６
２２をポイントするようにパッチされる６２０。同様
に、このコードのバージョン１のエントリー位置６２２
は、コードの次のバージョンをポイントするようにパッ
チされる６２４。ただし次のバージョンが関数１を削除
しないと仮定してであり、その場合、コードのバージョ
ン１のエントリー位置６２２はパッチされない。

【００８０】当業者には、様々なコード・バージョンを
前のバージョンに関連づけるパッチ機構が、このような
用途に使用されることが理解されよう。現在好ましい実
施の態様においては、以下のようなプロセスが使用され
る。元ファイルの各関数には、新たにコンパイル済みコ
ードの修正済み関数を呼び出す一連の命令がパッチされ
る。使用可能であれば、コンパイラにより提供される埋
込み領域が使用される。ＳＰＡＲＣにおけるパッチ命令
は（命令の順序はアーキテクチャにより異なる）次のよ
うになっている。関数「ｆｏｏ」（パッチしない）の最初部分の命令はこ
のようなものである。 foo-0x10:nop foo-c :nop foo-8 :nop foo-4 :nop エントリー => foo :sethi %hi(0xfffffc00),%g1 foo+4 :add %g1,920,%g1 foo+8 :save %sp,%g1,%sp ...

【００８１】この関数にＦｉｘを実行すると、関数エン
トリーに「ｊｍｐ」をパッチし、新たにコンパイル済み
関数「ｆｏｏ」の呼出しとともに埋込み領域に３つの命
令をパッチする。 foo-0x10:save %sp,-96,%sp foo-c :call foo' foo-8 :restore foo-4 :nop エントリー => foo :ba,a.-0x10 foo+4 :add %g1,920,%g1 foo+8 :save %sp,%g1,%sp ...

【００８２】埋込み領域が使用可能でない場合、関数の
最初の４つの命令が使用される。

【００８３】修正および継続再コンパイルの属性好ましい実施の態様における修正および継続の発明によ
り発行される再コンパイル・コマンドは、本来デバッグ
情報を備えていない再コンパイル・コードにデバッグ情
報を加えるため、または、再コンパイルされるコード行
を変更するために使用することができる。これは、デバ
ッガの修正および継続部分を使用し、ユーザが任意に適
切なフラグを設定することにより行われる。

【００８４】修正および継続上記の説明は、好ましい実施の態様において修正および
継続の発明を行い、使用するステップを開示する。当業
者には、様々なフラグおよびスタブの代替実施、代替コ
ード・システム、コンパイラ、リンカ、様々なディスプ
レイ・システムおよびプロセッサ・プラットフォームを
利用して、同様の発明を成し遂げることができることが
理解されよう。したがって、特定の典型的実施の態様が
詳細にわたり説明され、添付の図により示されている
が、このような実施の態様は単に例示的なものであって
広義の発明を制限するものではなく、当業者には様々な
他の変更も可能であるので、本発明は、ここに示され説
明された特定の配向および構造に制限されるものではな
いことを理解されたい。

【図面の簡単な説明】

【図１】本発明による、動的パッチングを使用する実
行時エラー・チェック・システムの全ブロック図であ
る。

【図２】本発明による、実行時エラー・チェック用動
的パッチングの一般的な流れ図である。

【図３】本発明による、実行時エラー・チェック方式
用動的パッチングを示す図である。

【図４】伝統的デバッグ修正ターンアラウンド・サイ
クルおよび本発明による修正および継続サイクルを示す
図である。

【図５】従来技術における伝統的デバッグ修正ターン
アラウンド・サイクルを示す、ブロック図である。

【図６】Ｆｉｘコマンドにより行われるステップを示
すブロック図である。

【図７】デバッグ・セッション開始時にロードされた
オリジナル・コード・バージョンと、その後の修正およ
び継続操作の結果生じた再コンパイル済みバージョンと
の関係を示す図である。

【図８】修正および継続システムのプログラム・カウ
ンタ・リセット方法体系を示す流れである。

【図９】Ｐｏｐコマンドの操作を示す流れである。

【図１０】コンストラクタ／デストラクタ・ツリーお
よび関連コード・セットを示す図である。

【符号の説明】

３０１ディスク・ファイル３０２オリジナル・プログラム３０３コンピュータ３０４入／出装置３０５メモリ３０６ＣＰＵ３０７デバッガ・プログラム３０８プログラム（メモリ内コピー）３０９実行時チェック（ＲＴＣ）モジュール３１０共用ライブラリ３１２プログラム・カウンタ（ＰＣ）

───────────────────────────────────────────────────── フロントページの続き (72)発明者ウェイン・シイ・グラムリッチアメリカ合衆国 94086 カリフォルニア州・サニーヴェイル・ヘンリエッタアヴェニュ・726 (72)発明者エドゥアルド・ペレグリ−ロパートアメリカ合衆国 94040 カリフォルニア州・マウンテンビュー・フォードハムウェイ・1731 (72)発明者テレンス・シイ・ミラーアメリカ合衆国 94025 カリフォルニア州・メンロパーク・オークコート・ 169

Claims

【特許請求の範囲】

【請求項１】プロセッサ、プログラム・カウンタ、メ
モリおよびプログラム命令を含むコンピュータ・システ
ムでコンピュータ・アプリケーション・プログラムをデ
バッグする方法において、その方法は前記プログラム命
令により実行され、デバッグ・セッション中に前記コンピュータ・アプリケ
ーション・プログラム内のエラーを検出するステップ
と、前記デバッグ・セッションを終了することなく、前記エ
ラーを含むプログラム・コードを修正するステップと、前記エラーが発生した前記デバッグ・セッションを再ス
タートすることにより、前記修正プログラムを使用して
デバッグ・セッションを継続するステップとを有するこ
とを特徴とするデバッグ方法。
【請求項２】前記デバッグ・セッションを終了するこ
となく、エラーを含むプログラム・コードを修正する前
記ステップがさらに、コンパイラを呼出し、前記エラーを訂正する修正事項を
含む編集ソース・コードのファイルをコンパイラに渡す
ステップと、前記編集ソース・コードのファイルに対応する、再コン
パイル済みオブジェクト・コード・ファイルを、コンパ
イラから受け取るステップと、前記再コンパイル済みオブジェクト・コード・ファイル
に対応する動的ライブラリ・ファイルを作成するステッ
プと、前記動的ライブラリ・ファイルを、前記コンピュータ・
アプリケーション・プログラムにリンクするステップ
と、コンピュータ・アプリケーション・プログラムを、前記
動的ライブラリ・ファイルを指すようにパッチするステ
ップと、プログラム・カウンタをリセットするステップと、前記再コンパイル済みオブジェクト・コード・ファイル
へブレーク・ポイントを移動させるステップとを含むこ
とを特徴とする請求項１に記載のコンピュータ・アプリ
ケーション・プログラムをデバッグする方法。
【請求項３】プロセッサ、プログラム・カウンタ、メ
モリおよびプログラム命令を含むコンピュータ・システ
ムでコンピュータ・アプリケーション・プログラムをデ
バッグする方法において、その方法は前記プログラム命
令により実行されるものであって、前記メモリにデバッガ・コンピュータ・プログラムをロ
ードするステップと、前記メモリに、コンパイル済みコンピュータ・アプリケ
ーション・プログラムのソース・コードおよびオブジェ
クト・コードをロードするステップと、前記デバッガ・コンピュータ・プログラムに、前記コン
パイル済みコンピュータ・アプリケーション・プログラ
ムのオブジェクト・コードの実行時実行を開始するよう
要求するステップと、エラーが発見された場合、前記デバッガ・コンピュータ
・プログラムにおいて修正および継続ルーチンを実行す
るステップであって、前記エラーを含むソース・ファイ
ルが編集され、前記エラーを含む前記ソース・コード・
ファイルの再コンパイル済みオブジェクト・コードが、
前記コンパイル済みコンピュータ・アプリケーション・
プログラムの前にロードされたオブジェクト・コードに
パッチされるステップと、前記デバッガが、コンパイルされた編集済みコンピュー
タ・アプリケーション・プログラム・オブジェクト・コ
ードの前記実行時実行を再開し、前記再開が前記エラー
の検出された前記再コンパイル済みオブジェクト・コー
ドの領域内においてなされるステップとを有することを
特徴とするデバッグ方法。
【請求項４】エラーが発見された場合、前記デバッガ
・コンピュータ・プログラムにおける修正および継続ル
ーチンを実行する前記ステップが、さらに、コンパイラを呼び出し、前記エラーを訂正する修正事項
を含む編集済みソース・コードのファイルをコンパイラ
に渡すステップと、前記編集済みソース・コードのファイルに対応する再コ
ンパイル済みオブジェクト・コード・ファイルをコンパ
イラから受け取るステップと、前記再コンパイル済みオブジェクト・コード・ファイル
を、対応する前記オブジェクト・コード・ファイルの前
のバージョンにリンクするステップと、プログラム・カウンタをリセットするステップと、前記再コンパイル済みオブジェクト・コード・ファイル
に、ブレーク・ポイントを移動させるステップと、デバッグ・プロセスが継続される前記アプリケーション
・プログラムを、プログラム・カウンタにより指示され
た位置で再スタートさせるステップとを含むことを特徴
とする請求項３に記載のコンピュータ・アプリケーショ
ン・プログラムをデバッグする方法。
【請求項５】プログラム・カウンタ、メモリおよびプ
ログラム命令とを有するプロセッサと、デバッグ・セッション中に前記コンピュータ・アプリケ
ーション・プログラムにおいてエラーを検出するように
構成され、前記プロセッサにより前記デバッグ・セッシ
ョンが実行される前記メモリ内のデバッガとを備え、前記デバッガが、前記デバッグ・セッションを終了することなく、前記エ
ラーを含むプログラム・コードを修正するための修正サ
ブシステムと、前記修正済みプログラム・コードを使用して、前記エラ
ーが発生した前記デバッグ・セッションを再スタートす
るための継続サブシステムとを有していることを特徴と
するコンピュータ・アプリケーション・プログラムをデ
バッグするコンピュータ・システム。
【請求項６】前記修正サブシステムが、コンパイラを呼び出し、前記エラーを訂正する編集事項
を含む編集済みソース・コードのファイルをコンパイラ
に渡すよう構成された呼出し機構と、前記編集済みソース・コードのファイルに対応する再コ
ンパイル済みオブジェクト・コード・ファイルをコンパ
イラから受け取るよう構成された通信機構と、前記再コンパイル済みオブジェクト・コード・ファイル
を、対応する前記オブジェクト・コード・ファイルの前
のバージョンに連結することのできるリンク機構と、前記プログラム・カウンタを変更できるプログラム・カ
ウンタ制御機構と、ブレーク・ポイントを前のオブジェクト・コード・ファ
イルから前記再コンパイル済みオブジェクト・コード・
ファイルに移動することのできるブレーク・ポイント配
置機構とを含んでいることを特徴とする請求項５に記載
のコンピュータ・アプリケーション・プログラムをデバ
ッグするコンピュータ・システム。
【請求項７】デバッグ・セッション中に前記コンピュ
ータ・アプリケーション・プログラム内のエラーを検出
する手段と、前記デバッグ・セッションを終了することなく前記エラ
ーを含むプログラム・コードを修正する手段と、前記エラーの発生した前記デバッグ・セッションを再ス
タートすることにより、前記修正プログラム・コードを
使用したデバッグ・セッションを継続する手段とを有す
ることを特徴とするプロセッサ、プログラム・カウン
タ、メモリおよびプログラム命令を備えたコンピュータ
でコンピュータ・アプリケーション・プログラムをデバ
ッグするシステム。
【請求項８】プロセッサ、プログラム・カウンタ、メ
モリおよびプログラム命令を含むコンピュータ・システ
ムで、コンピュータ・アプリケーション・プログラムを
デバッグする方法において、その方法は前記プログラム
命令により実行されるものであって、デバッグ・セッション中に前記コンピュータ・アプリケ
ーション・プログラム内のエラーを検出するステップ
と、前記デバッグ・セッションを終了することなく、前記エ
ラーを含むプログラム・コードを修正し、前記修正操作
によりユーザがデバッグ情報を加えるよう指定でき、前
記ユーザが修正すべきコード行を変更することができる
ステップと、前記エラーが発生した前記デバッグ・セッションを再ス
タートすることにより、前記修正プログラムを使用して
デバッグ・セッションを継続するステップとを有するこ
とを特徴とするデバッグ方法。
【請求項９】プログラム・カウンタ、メモリおよびプ
ログラム命令とを有するプロセッサと、デバッグ・セッション中に前記コンピュータ・アプリケ
ーション・プログラム内のエラーを検出するように構成
され、前記プロセッサにより前記デバッグ・セッション
が実行される前記メモリ内のデバッガとを備え、前記デバッガが、前記デバッグ・セッションを終了することなく前記エラ
ーを含むプログラム・コードをユーザが修正でき、前記
ユーザがデバッグ情報を加えるよう指定でき、前記ユー
ザが修正すべきコード行を変更することができる修正サ
ブシステムと、前記修正済みプログラム・コードを使用して、前記エラ
ーが発生した前記デバッグ・セッションを、ユーザが再
スタートすることのできる継続サブシステムとを有して
いることを特徴とするコンピュータ・アプリケーション
・プログラムをデバッグするためのコンピュータ・シス
テム。