JP2008052688A - プログラムのパッチデータ生成装置 - Google Patents

Abstract

【課題】 デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、前記ソースプログラムに含まれる関数や変数を用いた検査ルーチンを生成するパッチデータ生成装置を提供する。
【解決手段】 デバッグ対象のソースプログラムをコンパイルリンクして得られるデバッグ情報を用いて、デバッグ対象の機械語命令列に含まれる関数や変数を利用するためのパラメータを自動的に生成し、デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、デバッグ対象のソースプログラムの任意に記述された関数や変数を用いた検査ルーチンの生成し、デバッグ対象の機械語命令列に適用可能なパッチデータを生成する。
【選択図】図１

Description

本発明は、プログラムの動作検証に使用するプログラムのパッチデータ生成装置に関する。

コンピュータ用プログラムの作成にあたっては、そのプログラムが正常に動作するかどうかを検証するためのデバッグ作業が必要である。そのため、検査対象の記述部分に検査ルーチンを組み込み、ターゲットシステム上で実行することが行われる。

つまり、検査用ソースプログラムが組み込まれたデバッグ対象のソースプログラムをコンパイルリンクすることで、前記検査ルーチンの組み込みを行い、これによって得られた機械語命令列をターゲットシステム上で実行することによって動作状況の確認を行うのである。

しかしながら、カットアンドトライを要するようなプログラムのデバッグを行うケースでは、検査ソースプログラムを組み込んだデバッグ対象のソースプログラムから、デバッグ対象の機械語命令列を生成するコンパイルリンク作業そのものを繰り返し行う必要があり、このコンパイルリンク作業に要する時間がプログラムのデバッグ作業の工程上、無視出来ないレベルとなることも珍しくない。

そこで、従来、検査ルーチンの組み込みに対して、種々の自動化の提案が行われている（例えば、特許文献１参照。）。

この特許文献１においては、プログラムへのパッチ方法に関する公知の技術（例えば、特許文献２及至３参照。）に基づいて、デバッグ対象のソースプログラムをコンパイルリンクすることなく機械語命令列からなる検査ルーチンを組み込む手段を設け、前記検査ルーチンの組み込まれた機械語命令列を取得することが提案されている。

しかしながら、前述した手法では、Ｃ、Ｃ＋＋、パスカルといった高級言語を用いたプログラムのデバッグにおいて、機械語命令列からなる検査ルーチンから、デバッグ対象のソースプログラムの任意に記述された関数や変数を利用する場合、これらの利用規則を満たした検査ルーチンを生成し、利用可能とする為には、前記利用規則を満たす為の作業を手作業で行う必要がある。 更に、これに要する作業は必ずしも容易ではないため、最終的にはデバッグ対象のソースプログラムに検査ソースプログラムを組み込んだ上で再コンパイルリンクを行う手段をとることを選択せざるを得ない場合も少なくない。
特開２００５−１１５６１９ 特開平０５−１２００６７ 特開平０５−１８１６６４ ＤＷＡＲＦ Ｄｅｂｕｇｇｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ Ｗｏｒｋｇｒｏｕｐ、″ＤＷＡＲＦ Ｄｅｂｕｇｇｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎ ３″、［ｏｎｌｉｎｅ］、平成１７年１２月２０日、Ｆｒｅｅ Ｓｔａｎｄａｒｄ Ｇｒｏｕｐ、［平成１８年８月２３日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｄｗａｒｆ．ｆｒｅｅｓｔａｎｄａｒｄｓ．ｏｒｇ／Ｄｏｗｎｌｏａｄ．ｐｈｐ＞ Ｒｉｃｈａｒｄ Ｅａｒｎｓｈａｗ、″Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ Ｓｔａｎｄａｒｄ ｆｏｒ ｔｈｅ ＡＲＭ（Ｒ）Ａｒｃｈｉｔｅｃｔｕｒｅ ＧＥＮＣ−００３５３４″、［ｏｎｌｉｎｅ］、平成１８年５月４日、ＡＲＭ Ｌｉｍｉｔｅｄ、［平成１８年８月２３日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ａｒｍ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ＤｅｖＴｏｏｌｓ／ＡＢＩ．ｈｔｍｌ＞

これは、従来の手法では、前記関数の利用に必要な引数の受け渡し方法、前記関数からの戻り値の受け渡し方法、前記変数の値の格納場所、およびデータサイズの特定方法、およびその利用可否に関する情報、など、前記関数と前記変数を利用するために必要な、利用条件に関するパラメータの取得が自動化されていないことが主な原因である。

例えば、関数の呼出において必要な引数の受け渡しについて述べると、引数の個数や、引数の型が個々の関数によって様々であるため、デバッグ対象のソースプログラムをコンパイルリンクすることによって生成されるデバッグ対象の機械語命令列における関数の引数の受け渡しに用いられる媒体は、ターゲットＣＰＵのレジスタであったり、ターゲットメモリ上のスタックであったりと多様である。

つまり、検査ルーチンから、デバッグ対象のソースプログラムの任意に記述された関数や変数を利用する場合、これらの利用規則に関するパラメータを検査ルーチン生成部に自動的に入力し、検査ルーチン生成部はこれに基づいて、当該検査ルーチンの機械語命令列をデバッグ対象の機械語命令列に適用可能なパッチデータとして生成することが可能であれば、従来よりも更にプログラムのデバッグ作業の効率を高めることが出来る。

そこで、本発明の目的は、デバッグ対象のソースプログラムをコンパイルリンクして得られるデバッグ情報を基に前記パラメータを自動的に生成して、前記パラメータを検査ルーチン生成部に入力することで、デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、デバッグ対象のソースプログラムの任意に記述された関数や変数を用いた検査ルーチンの生成を自動化することにある。

本発明の一態様によれば、デバッグ対象のソースプログラムをコンパイルリンクして得られるデバッグ対象の機械語命令列と、前記コンパイルリンクによって得られるデバッグ情報を入力し、前記デバッグ対象のソースプログラムの任意に記述された関数の呼出と、前記デバッグ対象のソースプログラムの任意に記述された変数の利用を含む、高級言語で記述された検査ソースプログラムの挿入指示に従って、前記デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、前記デバッグ対象の機械語命令列に適用可能な、機械語命令列からなる検査ルーチンのパッチデータを生成することを特徴とする、プログラムのパッチデータ生成装置が提供される。

また、本発明の別の一態様によれば、前記検査ソースプログラム内で、前記デバッグ対象のソースプログラムの任意に記述された関数と同じ、名称と、引数型と、戻り値型と、を持つ代替関数を記述することで、前記デバッグ対象のソースプログラムの任意に記述された関数を、前記代替関数に差し替える効果を持つパッチデータを生成することを特徴とする、請求項１記載のプログラムのパッチデータ生成装置が提供される。

本発明によれば、デバッグ対象のソースプログラムをコンパイルリンクして得られるデバッグ対象の機械語命令列と、前記コンパイルリンクによって得られるデバッグ情報を入力し、前記デバッグ対象のソースプログラムの任意に記述された関数の呼出と、前記デバッグ対象のソースプログラムの任意に記述された変数の利用を含む、高級言語で記述された検査ソースプログラムの挿入指示に従って、前記デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、前記デバッグ対象の機械語命令列に適用可能な、機械語命令列からなる検査ルーチンのパッチデータを生成することが可能となる。

また、本発明によれば、前記検査ソースプログラム内で、前記デバッグ対象のソースプログラムの任意に記述された関数と同じ、名称と、引数型と、戻り値型と、を持つ代替関数を記述することで、前記デバッグ対象のソースプログラムの任意に記述された関数を、前記代替関数に差し替える効果を持つパッチデータを生成することが可能となる。

以下、本発明の実施例を図面を参照して説明する。

図１は、本発明の実施例１に係るプログラムのパッチデータ生成装置の構成を示すブロック図である。

プログラムのパッチデータ生成装置１は、デバッグ対象のソースプログラム２１のデバッグのため、デバッグ対象のソースプログラム２１をコンパイルリンクして得られるデバッグ対象の機械語命令列２３の読み出しと、前記コンパイルリンクによって得られるデバッグ情報２２の読み出しと、検査ソースプログラム２４の読み書きと、デバッグ対象のソースプログラム２１の読み出しと、パッチデータ２５の書き込みと、を行うための記憶装置２、デバッグ対象のソースプログラムの状況などを表示するための表示装置３、検査ルーチン生成に関するコマンドなどを入力するための入力装置４が接続されている。

また、プログラムのパッチデータ生成装置１は、検査ルーチンを生成するために、検査ソースプログラム管理部１２、検査ルーチン挿入位置指定部１３、デバッグ情報管理部１４を備え、更に検査ソースプログラム管理部１２と、検査ルーチン挿入位置指定部１３と、デバッグ情報管理部１４と、デバッグ対象のソースプログラム２１と、デバッグ対象の機械語命令列２３と、から必要な情報を得ることで検査ルーチンの機械語命令列を生成する検査ルーチン生成部１５を備えている。

コマンド解析部１１は、入力装置４から入力されたコマンドを解析し、検査ソースプログラム管理部１２、検査ルーチン挿入位置指定部１３、および、検査ルーチン生成部１５に、それぞれの動作実行を指示する。

検査ルーチン挿入位置指定部１３は、デバッグ情報管理部１４から得られる情報を基に、デバッグ対象のソースプログラム２１における、検査ルーチン挿入に適した挿入位置の候補を表示装置３を介して使用者に伝えると共に、使用者が前記候補の中からコマンド解析部１１を介して指定した検査ルーチン挿入位置に関する情報を、検査ルーチン生成部１５の求めに応じて、検査ルーチン生成部１５に入力する。

検査ソースプログラム管理部１２は、記憶装置２からの検査ソースプログラム２４の読み出し、コマンド解析部１１を介して使用者が入力した検査ソースプログラムの保持、必要に応じて前記検査ソースプログラムを検査ソースプログラム２４として記憶装置２への書き込みを行うと共に、検査ルーチン生成部１５の求めに応じて、検査ソースプログラムを、検査ルーチン生成部１５に入力する。

デバッグ情報管理部１４は、デバッグ情報２２を基に、検査ルーチン挿入位置指示部１３が必要とする検査ルーチンの挿入に適した挿入位置の候補に関する情報、検査ルーチン生成部１５が必要とするデバッグ対象のソースプログラム２１の任意に記述された関数や変数についての情報を管理し、前記各々の求めに応じて提供する。

検査ルーチン生成部１５は、使用者からのコマンド解析部１１を介した指示によって動作を開始し、検査ソースプログラム管理部１２から挿入対象となる検査ソースプログラムと、検査ルーチン挿入位置指定部１３から検査ルーチンの挿入に適した位置情報と、デバッグ情報管理部１４から得られるデバッグ対象のソースプログラム２２の任意に記述された関数や変数に関する情報と、予めコマンド解析部１１に入力装置４を介して使用者より入力されたターゲットメモリの利用状況に関する情報と、デバッグ対象の機械語命令列２４と、を基に、検査ルーチンの機械語命令列を生成するコンパイラである。

このとき、検査ルーチン生成部１５は、デバッグ対象の機械語命令列２３に上書きすることよって適用するパッチデータ２５を生成し、記憶装置２に格納する。

次に、このプログラムのパッチデータ生成装置１におけるパッチデータの生成に関する動作について、図２〜図１０を用いて説明する。

図２（ａ）は、Ｃ言語で書かれたデバッグ対象のソースプログラムを示す。 尚、本実施例における、デバッグ情報はＤＷＡＲＦ２及びＤＷＡＲＦ３形式であり、本実施例を説明するにあたり、前記デバッグ情報を総称してＤＷＡＲＦ形式と記述することとする。
また、この説明に用いる機械語命令はコプロセッサを持たない３２ビットＡＲＭ命令である。 ＤＷＡＲＦ形式についての詳細は、非特許文献１「ＤＷＡＲＦ Ｄｅｂｕｇｇｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎ ３」を参照して頂きたい。

図３は、図２（ａ）に示したデバッグ対象のソースプログラムとデバッグ対象の機械語命令列の対応を容易に識別出来るよう、Ｃ言語ソースプログラムおよびアセンブラ言語の混在表記とし、あわせてデバッグ情報管理部１４から得られるブレークポイントを示した図である。

ブレークポイントは、デバッグ対象の機械語命令列に複数存在する部分集合の実行開始の始点となるアドレスであり、デバッグ対象のソースプログラムの対象行との組み合わせである。 従って、ブレークポイントは必ずしもデバッグ対象のソースプログラムの全ての行に存在する訳ではない。 ここでは、本発明についての解説を容易にする為、関数の先頭に位置するブレークポイントをプロローグ・ブレークポイント、関数の末尾に位置するブレークポイントをエピローグ・ブレークポイントと呼ぶこととし、図３に示した関数ｆｕｎｃ１では、ブレークポイント５３２がプロローグ・ブレークポイント、ブレークポイント５７２がエピローグ・ブレークポイントにそれぞれ該当する。

ブレークポイントは、ソースレベルデバッグに対応するデバッグ情報であれば、当然求めることが出来るものであるが、ＤＷＡＲＦ形式のデバッグ情報では、行番号プログラム（Ｌｉｎｅ−ｎｕｍｂｅｒ Ｐｒｏｇｒａｍ）と名付けられた中間コードを持ち、これに対応するインタプリタを用いて前記中間コードを実行することにより、これを求める事ができる。 図２（ｂ）は、図２（ａ）に示すソースプログラムにおける行番号プログラムの実行結果である。

図４は、図２（ａ）に示すデバッグ対象のソースプログラムに対して、本発明の実施によって検査ソースプログラムが挿入されるイメージを示したものであり、Ｃ言語で記述されたｉｆ文が１行挿入される様子を示している。 この文は図２（ａ）に示すデバッグ対象のソースプログラムに含まれる、関数ｆｕｎｃ１の引数ｉｎｔ ａと、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」のメンバである、ｖ３とｖ４とｍｓｇへの参照、局所変数「ｒｅｔ」への代入、関数ｌｏｇｏｕｔの呼出を含んでいる。

尚、本実施例における検査ソースプログラムの文は、デバッグ対象のソースプログラムの任意に記述された文への分岐を伴わない文に限定される。 ただし、検査ルーチン挿入の対象となるブレークポイントへの分岐は許されるので、挿入対象の文がｓｗｉｔｃｈ文、ｆｏｒ文、ｗｈｉｌｅ文、ｄｏ文であれば、挿入対象の文の内部でｂｒｅａｋ文を使用することは可能である。

本発明の実施にあたっては、先ず、図５（ａ）に示すように、表示装置３に挿入箇所となるデバッグ対象のソースプログラムの対象行を表示する。

次に、図５（ｂ）に示すように、入力装置４から、検査ソースプログラムを入力する。
ここでは、図４に示す１行のｉｆ文を検査ソースプログラムを挿入するのであるから、これを入力する。 この検査ソースプログラムは、関数ｆｕｎｃ１の引数ｉｎｔ ａを、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」のメンバであるｖ３とｖ４を加算した値で比較し、結果として引数ｉｎｔ ａが持つ値が小さければ、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」のメンバであるｍｓｇを引数として、関数ｌｏｇｏｕｔを呼び出し、前記関数ｌｏｇｏｕｔからの戻り値を、関数ｆｕｎｃ１の局所変数「ｒｅｔ」に格納するというものである。

ここで入力された検査ソースプログラムは、検査ソースプログラム管理部１２によって保持される。

検査ルーチンの挿入箇所は、デバッグ対象のソースプログラムの行のうち、プロローグ・ブレークポイントとエピローグ・ブレークポイントを除くブレークポイントに限定することが望ましい。

この理由を述べると、プロローグ・ブレークポイントと、エピローグ・ブレークポイントは、その外観とは異なり、デバッグ対象のソースプログラムの任意に記述した文を示すものではなく、関数の首尾においてコールフレームの調整などを行うために、コンパイラとリンカが独自に生成する機械語命令列の部分集合の開始アドレスを示すブレークポイントだからである。

検査ルーチンは、ここで選択したブレークポイントの示すアドレスに挿入されるので、ここでは、ソースコード５５に挿入したいのであるから、ソースコード５５に対応するブレークポイント５５２を選択する。 選択されたブレークポイント５５２の示すアドレス０ｘ８２５４は、検査ルーチン挿入位置指定部１３によって保持される。 尚、ソースコード５５に挿入するという意味は、デバッグ対象の機械語命令列に含まれるソースコード５５に該当する箇所で、本来ソースコード５５に対応する機械語命令列５５１が実行されるタイミングで、先に本発明の実施によって生成した検査ルーチンが実行され、続いてソースコード５５に該当する機械語命令列５５１が実行されるという事である。

この選択を受けて、検査ルーチン生成部１５は、先に入力され、検査ソースプログラム管理部１２によって保持されている検査ソースプログラムと、検査ルーチン挿入位置指定部１３によって保持されているブレークポイント５５２のアドレスである０ｘ８２５４を受け取る。

次に、検査ルーチン生成部１５は、前記検査ソースプログラムが使用する、関数ｆｕｎｃ１の引数ｉｎｔ ａ、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」のメンバであるｖ３とｖ４とｍｓｇ、および、戻り値を受け取る局所変数「ｒｅｔ」が、ブレークポイント５５２のアドレス０ｘ８２５４において利用可能であるかどうか、デバッグ情報管理部１４に問い合わせる。

デバッグ情報管理部１４は、検査ルーチン生成部１５の問い合わせを受けて、関数ｆｕｎｃ１の引数ｉｎｔ ａ、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」のメンバであるｖ３とｖ４とｍｓｇ、および、局所変数「ｒｅｔ」がブレークポイント５５２のアドレスにおいて有効であれば、各変数の所在を示すロケーション情報を返し、これらの変数が１つでも有効でなければ、処理続行は不可能なので、エラーとし、必要に応じて表示装置３を経由して使用者に知らせる。

デバッグ情報管理部１４から通知されるロケーション情報の種類は、絶対アドレス、ターゲットＣＰＵのレジスタ名、ターゲットＣＰＵのレジスタ名とオフセット値の組み合わせなどであるが、この例では、引数ｉｎｔ ａはターゲットＣＰＵのレジスタ、引数「ｓｔｒｕｃｔ ＰＡＲＡＭ ｋ」の各メンバはターゲットＣＰＵのレジスタＲ１１にオフセット値を加算したアドレスを所在とする、ターゲットメモリのスタック上に配置されている。

このロケーション情報は、ソースレベルデバッグに対応したデバッグ情報であれば求めることが出来る。 デバッガはプログラムを動作させながらデバッグを行うために、プログラムの実行過程での変数値や、関数の所在を使用者に知らせる必要があり、これらの所在を知る術をデバッガに持たせることがデバッグ情報の本来の役目でもある。

本実施例におけるデバッグ情報であるＤＷＡＲＦ形式では、ロケーション式（Ｌｏｃａｔｉｏｎ Ｅｘｐｒｅｓｓｉｏｎｓ）と名付けられた中間コードを持ち、これに対応するインタプリタを用いて前記中間コードを実行及び解析することで、変数の所在を知ることが出来る。 また、関数の所在についてはデバッグ情報エントリ（Ｄｅｂｕｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｎｔｒｙ）と名付けられた情報を、「．ｄｅｂｕｇ＿ｉｎｆｏ」と「．ｄｅｂｕｇ＿ａｂｂｒｅｖ」と名付けられたセクションが保持しており、これらを解析することで求めることが可能であり、これら一連の作業はソースレベルデバッガと呼ばれる一般的なデバッガにおいて、ごく当たり前に行われていることである。

前記ロケーション式によって変数の所在を求めるためには、プログラムカウンタの値が必要となる場合がある。 特に「．ｄｅｂｕｇ＿ｌｏｃ」と名付けられたセクションの解析にはプログラムカウンタの値が必須であり、一般的なデバッガにおける用途では、ターゲットシステム上でデバッグ対象の機械語命令列の実行を行うため、当然、プログラムカウンタの値を取得することができる。

しかしながら、本発明の実施においては、ターゲットシステム上でデバッグ対象の機械語命令列の実行を行うことなく前記ロケーション式を実行する必要がある。 ターゲットシステム上でデバッグ対象の機械語命令列を実行することなく、プログラムカウンタの値を取得することは一見困難なように思えるが、ここで必要とされるプログラムカウンタの値は、検査ルーチン実行時のアドレス値であり、検査ルーチンの挿入位置であるブレークポイント５５２が持つアドレス値がこれに該当する。 つまり、本実施例においては、ブレークポイント５５２が持つアドレス０ｘ８２５４をプログラムカウンタの値として、前記ロケーション式の実行及び解析を行うことで必要な結果を導き出す事が出来る。

図７及び図８は、図２（ａ）に記載した、本実施例におけるデバッグ対象のソースプログラムの関数ｆｕｎｃ１に関するデバッグ情報エントリの解析結果である。

前記デバッグ情報エントリは、「ＤＷ＿ＴＡＧ」で始まるタグと、タグに属する「ＤＷ＿ＡＴ」で始まる属性の組み合わせにより構成されており、これによって得られる関数ｆｕｎｃ１に関する情報は下記の通りである。

関数ｆｕｎｃ１の実体である機械語命令列は、タグ７０の属性７０１〜７０２より、ターゲットメモリ上の０ｘ８２３４から０ｘ８２８Ｂに配置されていることが分かる。 また、実行時のフレームベースはタグ７０の属性７０３に示すロケーション式からターゲットＣＰＵのレジスタＲ１１が持つ値であり、戻り値の型は、タグ７０の属性７０４〜７０６より４バイトで構成される符号付き整数値であることが分かる。

更に、前記関数の引数は、タグ７１より第一引数の名称は「ａ」で４バイトで構成される符号付き整数、タグ７２より第二引数の名称は「ｂ」で４バイトで構成される符号付き整数、タグ７３より第三引数の名称は「ｋ」、更にタグ７３２より名称が「ＰＡＲＡＭ」である構造体であり、タグ７３２２〜タグ７３２６より、第一メンバの名称は「ｖ１」で、４バイトで構成される符号付き整数値、第二メンバの名称は「ｖ２」で、４バイトで構成される符号付き整数値、第三メンバの名称はｖ３で、４バイトで構成される符号付き整数値、第四メンバの名称はｖ４で、４バイトで構成される符号付き整数値を各々扱う。 第五メンバの名称は、ｍｓｇで、１バイトで構成される符号付き整数値のポインタ変数で、前記ポインタ変数は４バイトで構成されていることがわかる。 更に、関数ｆｕｎｃ１はタグ７４より、局所変数を１つ持っていることがわかり、この局所変数は、属性７４０より名称「ｒｅｔ」、属性７４２〜７４４より、４バイトで構成される符号付き整数値を扱うことがわかる。

次に、前記各変数の所在をデバッグ情報エントリ及びロケーション式から求めると、第一引数は、属性７１４よりターゲットＣＰＵのレジスタＲ０、第二引数は属性７２４よりターゲットＣＰＵのレジスタＲ４、第三引数は、属性７３１より前記フレームベースであるターゲットＣＰＵのレジスタＲ１１の持つ値に４を加えたＲ１１＋４が示すアドレスを先頭として配置されており、以下同様に、メンバｖ１は属性７３２２４より前記Ｒ１１＋４＋０が示すアドレス上、メンバｖ２は属性７３２３４より前記Ｒ１１＋４＋４が示すアドレス上、メンバｖ３は属性７３２４４より前記Ｒ１１＋４＋８が示すアドレス上、メンバｖ４は属性７３２５４より前記Ｒ１１＋４＋１２が示すアドレス上、メンバｍｓｇは属性７３２２６より前記Ｒ１１＋４＋１６が示すアドレス上、局所変数ｒｅｔは属性７４より、ターゲットＣＰＵのレジスタＲ２を所在としていることが各々分かる。

前述の通り、前記デバッグ情報エントリ及び前記ロケーション式を解析することで、各変数の型と所在を知ることが出来るが、ここで注意すべき点は、前述した各変数の所在は、プロローグ・ブレークポイント５３２に属する機械語命令列５３１を実行した後の各変数の所在を示すことである。

但し、本実施例のデバッグ情報であるＤＷＡＲＦ形式は、「．ｄｅｂｕｇ＿ｆｒａｍｅ」と名付けられたセクションが持つ、コールフレーム情報と名付けられた、本来は「コールフレームの巻き戻し」と呼ばれるデバッグ機能をソースレベルデバッガが備えるために用いられる情報を用いて、機械語命令列５３１における前記各変数の所在を求めることも可能であることを念の為、付け加えておく。

尚、本実施例においては検査ソースプログラムから静的変数を扱う例が含まれていないが、静的変数も検査ソースプログラムから用いることが可能である。 本実施例におけるデバッグ情報であるＤＷＡＲＦ形式の場合、静的変数は、局所変数と同様にタグ「ＤＷ＿ＴＡＧ＿ｖａｒｉａｂｌｅ」が型及びロケーションを求めるための属性を持った形式で表現されている。静的変数が局所変数と大きく異なる点は、求められるロケーションがターゲットメモリ上のアドレスであるという点である。

次に、前述した関数ｆｕｎｃ１同様に、図２（ａ）に記載したデバッグ対象のソースプログラムの任意に記述された関数ｌｏｇｏｕｔについての情報を求める。 前記関数は、図４の検査ソースプログラム内で用いられており、図９は前記関数のデバッグ情報エントリ及びロケーション式の解析結果である。

前記関数ｌｏｇｏｕｔは、タグ８０の属性８０１〜８０２よりターゲットメモリ上のアドレス０ｘ８２１Ｃ〜０ｘ８２３３に配置され、フレームベースは属性８０３よりターゲットＣＰＵのレジスタＲ１１、戻り値の型はタグ８０の属性８０５〜８０６より、４バイトの符号付き整数値である。

更に、関数ｌｏｇｏｕｔは、タグ８１の属性８１０〜８１６より名称ｍｓｇである、１バイト符号付き整数値を示す４バイトで構成されるポインタ変数を唯一の引数として持ち、この引数の機械語命令列５０１を実行後の所在は、ターゲットＣＰＵのレジスタＲ０である。

尚、本実施例におけるデバッグ情報であるＤＷＡＲＦ形式における、関数の実行開始アドレスは、タグ「ＤＷ＿ＴＡ＿ｓｕｂｐｒｏｇｒａｍ」が属性「ＤＷ＿ＡＴ＿ｅｎｔｒｙ＿ｐｃ」を持っている限りにおいては、前記属性が持つアドレス値であり、前記属性を持たない場合は、属性「ＤＷ＿ＡＴ＿ｌｏｗｐｃ」が持つアドレス値である。 尚、インライン関数の実体である機械語命令コード列は、タグ「ＤＷ＿ＴＡＧ＿ｉｎｌｉｎｅｄ＿ｓｕｂｒｏｕｔｉｎｅ」として表記される。 更に、非連続のアドレス範囲に関数の実体である機械語命令列が配置されている場合、属性「ＤＷ＿ＡＴ＿ｒａｎｇｅ」によって、前述した非連続のアドレス範囲を求めることが出来る。

ここまでの解析作業で、本実施例に関連する各関数における引数の型、戻り値の型、変数の型及び所在を知ることが出来たのであるが、本実施例に於いて更に必要な情報として、実際に関数の実体である機械語命令列を呼出すために必要な、引数および戻り値の受け渡し方法を知る必要がある。

本実施例のデバッグ情報形式であるＤＷＡＲＦ形式は、前記した関数の引数および戻り値の受け渡し方法に関する情報を持っていない。 これは、ターゲットＣＰＵの製造者を中心として決定されるＡＢＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ ｉｎｔｅｒｆａｃｅ）と名付けられた仕様の一部である標準呼出規則（Ｔｈｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ Ｓｔａｎｄａｒｄ）に、デバッグ対象の機械語命令列を生成するために用いるコンパイラ及びリンカが準拠していることを前提としていることが理由である。 尚、前記ＤＷＡＲＦ形式には、前記標準呼出規則に関数の実体である機械語命令列が準拠しているかどうかをデバッガに知らせるための手段が準備されており、これはタグ「ＤＷ＿ＴＡＧ＿ｓｕｂｐｒｏｇｒａｍ」に付属する属性「ＤＷ＿ＡＴ＿ｃａｌｌｉｎｇ＿ｃｏｎｖｅｎｔｉｏｎ」が持つ値を調べることで知ることが出来る。尚、属性「ＤＷ＿ＡＴ＿ｃａｌｌｉｎｇ＿ｃｏｎｖｅｎｔｉｏｎ」が無い場合は、前記標準呼出規則に準拠していると解釈出来る。

図６は、本実施例におけるターゲットＣＰＵの前記ＡＢＩ仕様のうち本実施例に必要な部分を抜粋したものである。 これによれば、関数呼び出し時の引数は、ターゲットＣＰＵのレジスタＲ０〜Ｒ４と、ＳＰをスタックポインタとするターゲットメモリ上のスタック領域を経由して関数に引き渡され、また戻り値はターゲットＣＰＵのレジスタＲ０〜Ｒ１を用いて呼出元に返されることがわかる。

図１０（ａ）は、本実施例において検査ルーチン生成部１５が生成した検査ルーチンの機械語命令列である。 検査ルーチン生成部１５は、デバッグ情報管理部１４より前述したような検査ルーチン挿入に必要な一連の情報を取得し、入力装置４を介して使用者によって予め入力されたターゲットメモリの利用状況の情報を基に、検査ソースプログラムをコンパイルして検査ルーチンの機械語命令列を生成する。 生成された機械語命令列は、ターゲットメモリ上の未使用領域に配置され、かつ、関数ｆｕｎｃ１の動作を損なわないよう、結果を代入する局所変数ｒｅｔが割り当てられたターゲットＣＰＵのレジスタＲ２を除く全てのレジスタ値のスタックへの待避および復帰などの処理を含んでいる。

ここで注目すべきは、前記検査ルーチンの機械語命令列が前記関数ｆｕｎｃ１の一部として動作するように生成される点であり、また検査ソースプログラムには、前記検査ソースプログラムで用いられている変数や関数の型に関する情報を全く記述する必要が無いということである。つまり、前記一連の型情報は、これまでの説明の通りデバッグ情報から求めることが出来るので、検査ソースプログラム内で明示する必要がない。

次に、検査ルーチン生成部１５は図１０（ｃ）に示す通り、関数ｆｕｎｃ１に図１０（ａ）に示す検査ルーチンの機械語命令列を組み込むため、ブレークポイント５５２のアドレス０ｘ８２５４から、機械語命令列で構成される分岐命令を挿入するスペースに該当するデータ列を、デバッグ対象の機械語命令列２３から取得し、前述した検査ルーチンへの分岐命令に相当する機械語命令で置き換え、余分があればＮＯＰ相当の機械語命令で埋める。

更に、図１０（ｂ）に示す通り、前述した取得済みのブレークポイント５５２の示すアドレス０ｘ８２５４に存在した機械語命令を、前述した検査ルーチンの機械語命令列の末尾にアペンドし、必要ならアペンドした命令が持つアドレス値などを補正後、更に、図１０（ｃ）で示したブレークポイント５５２の示すアドレスにある検査ルーチンへの分岐命令の次のアドレスへの機械語命令で構成された分岐命令を生成して、これをアペンドする。

最後に、検査ルーチン生成部１５は、検査ルーチン挿入によって追加される部分と、デバッグ対象の機械語命令列２３の前記検査ルーチン挿入によって書き換えられる部分と、で構成されるパッチデータ２５を生成し、記憶装置２に格納する。このパッチデータの具体的な形式はインテルＨＥＸフォーマットやモトローラＳフォーマットなど既知の汎用フォーマットで足り、デバッグ対象の機械語命令列２３に上書きして用いる。

前述した検査ソースプログラムの挿入箇所として指定したブレークポイントにおける、検査ソースプログラム内で利用する変数が有効に利用可能であるかどうかを調べる手段に関して述べると、デバッグ情報の信頼性に著しく影響を受けやすい特性がある。

例えば、本実施例における検査ソースプログラムの挿入箇所を、ブレークポイント５５２ではなく、ブレークポイント５６２として実施する場合、機械語命令列５５１に記載された機械語命令５５１０が実行されると、引数ｉｎｔ ａが割り当てられているターゲットＣＰＵのレジスタＲ０が持つ値が書き換えられる。

しかしながら、属性７１４が示すロケーション式では、関数ｆｕｎｃ１が実行中である場合、引数ｉｎｔ ａは常にターゲットＣＰＵのレジスタＲ０に割り当てられていることが示されており、関数ｆｕｎｃ１における機械語命令列が示す挙動と一致しない。 つまり、図７及び図８は、不完全なデバッグ情報の例として用いることが出来る。

本実施例におけるデバッグ情報であるＤＷＡＲＦ形式においては、変数の所在がその消滅を含めて変化した場合に対応するため「．ｄｅｂｕｇ＿ｌｏｃ」と名付けられたセクションが持つ情報を基に、プログラムカウンタの値に応じた、特定の変数の所在及び有効性について知る術を提供しているのであるが、デバッグ情報を生成するコンパイラ及びリンカによっては、図７及び図８が示すような不完全なデバッグ情報を生成することも考慮しておく必要がある。

前述したような不完全なデバッグ情報を用いた場合、ソースレベルデバッガと呼ばれるデバッガにおいても、デバッグ情報が本来の目的とする機能性について同様の問題が発生する。 例えば、図７及び図８のデバッグ情報を入力した従来のソースレベルデバッガは、機械語命令５５１０を実行した後の引数ｉｎｔ ａの値をデバッグ対象のソースプログラムの記述から推測されるものとは異なる値として使用者に示すことになる。ここで述べた不完全なデバッグ情報は、最適化コンパイラによってもたらされる場合が多い。

この問題を解決するための手段としては、変数値が利用可能であるブレークポイント上で必要な変数が持つ値のコピーを生成し、検査ルーチン生成部が生成する検査ソースプログラムに対応する機械語命令列から前述したコピーを参照させるという手法が考えられる。 前述したコピーの格納場所としては、スタックポインタが示すコールフレームが最適であろう。

しかしながら、前記コールフレームを前記変数値のコピーの格納場所とする場合、検査ルーチン挿入の対象である関数のデバッグ対象の機械語命令列における動作を機械語命令レベルで解析する必要があるかもしれない。 具体的には、プロローグ・ブレークポイントとエピローグ・ブレークポイントに属さない前記関数の実体である機械語命令列において、前記スタックポインタを、参照及び書き換えしていないことを確認することである。
もし、前述したスタックポインタの、参照及び書き換えが行われている場合、コールフレームに前記コピーを格納するのは難しい。 尚、前記機械語命令列で用いられている標準呼出規則に準拠した関数の実体である機械語命令列へのサブルーチンコールは解析に含める必要がない。

従って、デバッグ対象のソースプログラム２１をコンパイルリンクして得られるデバッグ情報２２から得られる変数の所在に関するロケーション情報は、機械語命令列における変数値の格納場所について、その存在の有無を含めた正確な表現であることが望ましい。

つまり、ロケーション情報が前述したような正確な表現であれば、本実施例におけるブレークポイント５５２への検査ルーチンの挿入は正常に行われ、またブレークポイント５６２への検査ルーチンの挿入は、引数ｉｎｔ ａの値がブレークポイント５６２のアドレスにおいて不定であることを理由として、処理続行が不可能であることを表示装置３を介して使用者に知らせることが出来る。

次に、検査ソースプログラムの挿入箇所として使用者が指定するブレークポイントについて述べると、サイズ最適化を行うコンパイラ及びリンカを用いて生成されるデバッグ対象の機械語命令列は、デバッグ対象のソースプログラムにおいて見かけ上、独立した記述である複数の箇所を、同一アドレス範囲に置かれた機械語命令列を使い回すことで表現する傾向が時折見受けられる。

検査ルーチンの挿入に際して、前述した傾向が与える直接的な影響は、本発明を実施することによってデバッグ対象の機械語命令列に挿入される検査ルーチンが、使用者の意図した箇所以外で実行される可能性を否定できないという点である。

つまり、検査ルーチンの挿入に際して、前述した可能性を使用者に知らせるべきであり、具体的にはデバッグ情報から取得できるブレークポイント情報が、「同じアドレス」と「異なるソースプログラム記述行」の組み合わせから成るブレークポイントを複数持つなら、前記アドレスを示すブレークポイントは検査ルーチンの挿入に適さないブレークポイントであると考えられるので、表示装置３を介して使用者にその旨を知らせる。

更に、ブレークポイント情報が、「異なるアドレス」と「同じソースプログラム記述行」の組み合わせから成るブレークポイントを複数持つなら、前記ブレークポイントが示すデバッグ対象のソースプログラムの行が複数のブレークポイントを持つことを示し、本実施例において用いたＣ言語では、ｆｏｒ文がこの傾向を示すステートメントの１つである。
こうした傾向をブレークポイント情報から得られた場合、表示装置３を介して使用者にその旨を知らせる。

本実施例の検査ルーチンの挿入指示に際しては、前述したような情報を表示装置３を介して使用者に提供し、最終的な検査ルーチン挿入動作の可否は使用者が決定し、入力装置４を介して検査ルーチン生成部１５に指示する。

このような本実施例によれば、検査ルーチンとして挿入可能なステートメントに幾分制約があるものの、生成されるパッチデータのサイズを小さく抑えることができる。 つまり、従来のバイナリデータだけを比較する差分生成方式よりも、効率の良い検査ルーチンを生成することが出来る。 また、特定のインライン展開された関数の実体である機械語命令列への検査ルーチン挿入も可能となる。

図１１は、本発明の実施例２に係るプログラムのパッチデータ生成装置の構成を示すブロック図である。

プログラムのパッチデータ生成装置１００には、デバッグ対象のソースプログラム２１のデバッグのため、デバッグ対象のソースプログラム２１をコンパイルリンクして得られるデバッグ対象の機械語命令列２３の読み出しと、前記コンパイルリンクによって得られるデバッグ情報２２の読み出しと、検査ソースプログラム２４の読み書きと、パッチデータ２５の書き込みと、を行うための記憶装置２、パッチデータの生成状況などを表示するための表示装置３、検査ルーチン生成に関するコマンドなどを入力するための入力装置４が接続されている。

また、プログラムのパッチデータ生成装置１００には、検査ルーチンを生成するために、検査ソースプログラム管理部１２０、デバッグ情報管理部１４０を備え、更に検査ソースプログラム管理部１２０と、デバッグ情報管理部１４０と、デバッグ対象の機械語命令列２３から、必要な情報を得ることで検査ルーチンの機械語命令列を生成する既存関数差し替え部１５０を備えている。

コマンド解析部１１０は、入力装置４から入力されたコマンドを解析し、検査ソースプログラム管理部１２０、および、既存関数差し替え部１５０に、それぞれの動作実行を指示する。

検査ソースプログラム管理部１２０は、記憶装置２からの検査ソースプログラム２４の読み出しと、コマンド解析部１１０を介して使用者が入力した検査ソースプログラムの保持と、前記検査ソースプログラムを検査ソースプログラム２４として記憶装置２への書き込みと、既存関数差し替え部１５０の求めに応じて既存関数差し替え部１５０への検査ソースプログラムの入力と、を行う。

デバッグ情報管理部１４０は、デバッグ情報２２を基に、デバッグ対象のソースプログラム２１の任意に記述された関数や変数についての情報を管理し、既存関数差し替え部１５０の求めに応じて提供する。

既存関数差し替え部１５０は、使用者からのコマンド解析部１１０を介した指示によって動作を開始し、検査ソースプログラム管理部１２０から代替関数の記述を含んだ検査ソースプログラムと、デバッグ情報管理部１４０から得られるデバッグ対象のソースプログラム２１の任意に記述された既存関数に関する情報と、予めコマンド解析部１１０に入力装置４を介して使用者より入力されたターゲットメモリの利用状況に関する情報と、デバッグ対象の機械語命令列２３と、を基に、デバッグ対象のソースプログラム２１に任意に記述された関数（以下、既存関数）を、前記関数と同じ、引数の型と、戻り値の型と、名称と、を持つ前記検査ソースプログラムに記述された関数（以下、代替関数）に差し替えるために必要な、デバッグ対象の機械語命令列２３に上書きすることによって適用するパッチデータ２５を生成し、記憶装置２に格納するコンパイラである。

次に、このプログラムのパッチデータ生成装置１００におけるパッチデータ２５の生成に関する動作について、図２（ａ）、図３、図６〜図９、図１２〜図１４を用いて説明する。 尚、図２（ａ）、図３、図６〜図９は実施例１と重複するが、本実施例の説明に必要とする図面と同一内容であるので、本実施例の説明に利用する。

本実施例における、デバッグ情報は同様にＤＷＡＲＦ２及びＤＷＡＲＦ３形式であり、本実施例を説明するにあたり、前記デバッグ情報を総称してＤＷＡＲＦ形式と記述することとする。 また、この説明に用いる機械語命令はコプロセッサを持たない３２ビットＡＲＭ命令である。 ＤＷＡＲＦ形式についての詳細は、非特許文献１「ＤＷＡＲＦ Ｄｅｂｕｇｇｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎ ３」を参照して頂きたい。

図２（ａ）は、Ｃ言語で記述されたデバッグ対象のソースプログラムであり、本実施例における既存関数ｆｕｎｃ１の記述を含む。

図１２は、本実施例によって生成されるパッチデータ２５を適用することで、デバッグ対象の機械語命令列に組み込まれる代替関数ｆｕｎｃ１のソースプログラムである。 この関数は図２（ａ）に含まれる既存関数ｆｕｎｃ１と同じ、引数の型と、戻り値の型と、名称と、を持っている。

本発明の実施にあたっては、図１３（ａ）に示すように、先ず、使用者は、入力装置４を介してコマンド解析部１１０に代替関数ｆｕｎｃ１の記述を含む検査ソースプログラムを入力する。 コマンド解析部１１０は、入力された前記検査ソースプログラムを検査ソースプログラム管理部１２０に引き渡し、検査ソースプログラム管理部１２は前記検査ソースプログラムを保持する。

次に、使用者は図１３（ｂ）に示すように、入力装置４を介してコマンド解析部１１０に関数の差し替え実行を指示する。 この指示を受けてコマンド解析部１１０は、既存関数差し替え部１５０に対して、関数の差し替え実行を指示する。

この指示を受けて、既存関数差し替え部１５０は、検査ソースプログラム管理部１２０が保持している検査ソースプログラムを取得して、関数の宣言部のみを対象としたＣ言語の構文解析を行い、前記検査ソースプログラムに記述された関数の、名称と、引数の型と、戻り値の型と、を各々求める。 この結果、既存関数差し替え部１５０は、前記検査ソースプログラムに記述された関数の名称が「ｆｕｎｃ１」であることがわかる。 また、引数の型については、第一引数「ｉｎｔ」、第二引数「ｉｎｔ」、第三引数「ｓｔｒｕｃｔ ＰＡＲＡＭ」であることが各々分かる。 更に、戻り値の型が「ｉｎｔ」であることもわかる。

次に、既存関数差し替え部１５０は、デバッグ情報管理部１４０に対して、前記構文解析により取得した代替関数ｆｕｎｃ１と同じ、引数の型と、戻り値の型と、名称と、を備えた既存関数ｆｕｎｃ１の実体がデバッグ対象の機械語命令列２３に存在するか否かを問い合わせる。

この問い合わせを受けてデバッグ情報管理部１４０は、デバッグ情報２２を基に、前記代替関数ｆｕｎｃ１と同じ、引数の型と、戻り値の型と、名称と、を備えた関数の実体である機械語命令列がデバッグ対象の機械語命令列２３に存在するか否かを調査し、結果を既存関数差し替え部１５０に返す。

既存関数差し替え部１５０が、デバッグ情報管理部１４０より、既存関数ｆｕｎｃ１の実体がデバッグ対象の機械語命令列２３に存在するとの結果を受けた場合、更にデバッグ情報管理部１４０に対して、既存関数ｆｕｎｃ１の実体である機械語命令列が配置されるターゲットメモリ上のアドレス範囲、前記機械語命令列における実行開始アドレス、第一引数〜第三引数の型情報を各々問い合わせる。 尚、既存関数ｆｕｎｃ１の実体がデバッグ対象の機械語命令列２３に存在しないとの結果を受けた場合、以後の処理続行は不可能なので、表示装置３を介して使用者にその旨を知らせる。

デバッグ情報管理部１４０は、既存関数差し替え部１５０からの要求を受けて、デバッグ情報２２を基に、既存関数ｆｕｎｃ１の実体である機械語命令列が配置されているターゲットメモリ上のアドレス範囲、前記機械語命令列の実行開始アドレス、第一引数〜第三引数の型を各々取得し、既存関数差し替え部１５０に返す。

既存関数差し替え部１５０は、図１４（ａ）で示す通り、デバッグ情報管理部１４０から取得した、既存関数ｆｕｎｃ１の第一引数〜第三引数の型および戻り値の型と、ＡＢＩ仕様の一部である標準呼出規則（Ｔｈｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ Ｓｔａｎｄａｒｄ）と、コマンド解析部１１０に予め使用者によって入力されたターゲットメモリの利用状況の情報と、を各々用いて検査ソースプログラム管理部１２から受け取った代替関数ｆｕｎｃ１のソースプログラムをコンパイルし、機械語命令列を生成する。 尚、前記機械語命令列が配置されているターゲットメモリ上のアドレス領域は、入力装置４及びコマンド解析部を経て予め使用者により入力されたターゲットメモリ上の空き領域である。

既存関数差し替え部１５０は、前記コンパイルの過程において代替関数ｆｕｎｃ１のソースプログラムに記述されている局所変数ｒｅｔの型の実体を構成するための情報をデバッグ情報管理部１４０に問い合わせる。

デバッグ情報管理部１４０は、前記問い合わせを受けて、局所変数ｒｅｔの実体を構成するための情報を、ターゲットＣＰＵの製造者を中心として決定されるＡＢＩ仕様に基づいて既存関数差し替え部１５０を返す。 局所変数ｒｅｔの型は前記コンパイルにおける構文解析でｉｎｔであることが分かるから、本実施例におけるターゲットＣＰＵのアーキテクチャの前記ＡＢＩ仕様より、４バイトで構成される符号付き整数であることがわかる。尚、既存関数に記述された同じ初期値を伴う静的変数を除いて、初期化を伴う静的変数を検査ソースプログラムに記述するには注意を要するので、表示装置３を介して使用者にその旨を知らせる。この理由を述べると、静的変数の実体をターゲットメモリの空き領域に準備することは可能であるが、初期化には別の手段が必要であると考えられるからである。

既存関数差し替え部１５０は、デバッグ情報管理部１４０から前述した情報を受け取り、局所変数ｒｅｔの実体がスタックポインタが示すコールフレームに割り当てられるように機械語命令列を生成する。

更に、既存関数差し替え部１５０は、前記ソースプログラムで用いられている関数ｌｏｇｏｕｔの、引数と、戻り値と、実行開始アドレスと、の情報を、デバッグ情報管理部１４０に問い合わせる。

デバッグ情報管理部１４０は前記問い合わせを受けて、デバッグ情報２２を基に、図９に示すように関数ｌｏｇｏｕｔのデバッグ情報エントリを解析し、既存関数差し替え部１５０に対して関数ｌｏｇｏｕｔの、引数と、戻り値と、実行開始アドレスと、の情報を返す。この解析は実施例１における関数ｌｏｇｏｕｔに関する記述と同一である。

既存関数差し替え部１５０は、デバッグ情報管理部１４０から前述した情報を受け取り、関数ｌｏｇｏｕｔの呼び出しを行うための機械語命令列を生成する。

続いて、既存関数差し替え部１５０は、図１４（ｂ）に示す通り、前述したデバッグ情報管理部１４０から取得した既存関数ｆｕｎｃ１の実行開始アドレスである０ｘ８２３４に、前記コンパイルによって生成された図１４（ａ）に示す機械語命令列の実行開始アドレス０ｘＡ０００への機械語命令による無条件分岐命令を書き込む。

最後に、既存関数差し替え部１５０は、前述した一連の動作によって生成された、図１４（ａ）に示す代替関数ｆｕｎｃ１の機械語命令列および図１４（ｂ）に示すデバッグ対象の機械語命令列２３における置き換え箇所から構成される、デバッグ対象の機械語命令列２３に適用可能なパッチデータ２５を生成し、記憶装置２に格納する。このパッチデータの具体的な形式は、インテルＨＥＸフォーマットやモトローラＳフォーマットなどの汎用的な既存のフォーマットで足り、デバッグ対象の機械語命令列２３に上書きして用いる。

前述した、デバッグ情報管理部１４０が行う、代替関数ｆｕｎｃ１と同じ、名称と、引数の型と、戻り値の型と、を持つ、既存関数ｆｕｎｃ１の探索処理について詳しく述べると、デバッグ情報管理部１４０は、デバッグ情報２２のセクション「．ｄｅｂｕｇ＿ｉｎｆｏ」と「．ｄｅｂｕｇ＿ａｂｂｒｅｖ」が示すデバッグ情報エントリ全体について、タグ「ＤＷ＿ＴＡＧ＿ｓｕｂｐｒｏｇｒａｍ」及びタグ「ＤＷ＿ＴＡＧ＿ｉｎｌｉｎｅｄ＿ｓｕｂｒｏｕｔｉｎｅ」に属する、関数名を示す属性「ＤＷ＿ＡＴ＿ｎａｍｅ」が持つ文字列に着目し、前記文字列がｆｕｎｃ１であれば、更に前記タグが示す関数の引数と戻り値が、代替関数ｆｕｎｃ１と同じ、引数の型と、戻り値の型と、を持つか調べる。

図７及び図８は、既存関数ｆｕｎｃ１のデバッグ情報エントリの解析結果である。 既存関数ｆｕｎｃ１と、前記代替関数ｆｕｎｃ１の、引数及び戻り値の型情報が一致する様子を下記に示す。

まず、前述した既存関数ｆｕｎｃ１について述べると、の戻り値の型はタグ７０の属性７０４〜７０６より４バイトで構成される符号付き整数「ｉｎｔ」、第一引数はタグブロック７１より４バイトで構成される符号付き整数値「ｉｎｔ」、第二引数はタグブロック７２より４バイトで構成される符号付き整数値「ｉｎｔ」、第三引数はタグブロック７３より名称が「ＰＡＲＡＭ」である構造体であり、更に前記構造体のメンバについてタグ７３２２〜タグ７３２６より、第一メンバは名称が「ｖ１」である４バイトで構成される符号付き整数「ｉｎｔ」、第二メンバは名称が「ｖ２」である４バイトで構成される符号付き整数「ｉｎｔ」、第三メンバは名称がｖ３である４バイトで構成される符号付き整数「ｉｎｔ」、第四メンバは名称がｖ４である４バイトで構成される符号付き整数「ｉｎｔ」、第五メンバは名称がｍｓｇで、１バイトで構成される符号付き整数「ｃｈａｒ」を取り扱うポインタ変数であり、前記ポインタ変数は４バイトで構成されていることが各々わかる。

引数の型及び戻り値の型に関して、前述した既存関数ｆｕｎｃ１と、前記構文解析によって取得した代替関数ｆｕｎｃ１を比較すると、第三引数「ｓｔｒｕｃｔ ＰＡＲＡＭ」のメンバ構成が代替関数ｆｕｎｃ１において不明であることを除いて、第一引数〜第三引数の型と、戻り値の型は全て一致する。 尚、ここでは代替関数ｆｕｎｃ１の引数のうち、「ｉｎｔ」及び「ｃｈａｒ」のバイナリレベルでの構成が不明なように思えるが、これに関しては、既存関数ｆｕｎｃ１における「ｉｎｔ」及び「ｃｈａｒ」と同一であると解釈しても差し支えない。

第三引数「ｓｔｒｕｃｔ ＰＡＲＡＭ」の型一致については、代替関数ｆｕｎｃ１を含む検査ソースプログラム内で特に定義されない限りは、既存関数ｆｕｎｃ１の第三引数「ｓｔｒｕｃｔ ＰＡＲＡＭ」の型と同一であると仮定することで、検査ソースプログラム上で前記「ｓｔｒｕｃｔ ＰＡＲＡＭ」の定義を省略することが出来るが、厳密に「ｓｔｒｕｃｔ ＰＡＲＡＭ」のメンバ構成を確認することは出来ない。

次に、既存関数がインライン展開されている場合について詳しく述べると、前記関数の実体である機械語命令列の動作を機械語命令レベルで解析する必要に迫られる場合がある。 この理由を述べると、インライン展開された関数の差し替えを実施するためには、前記関数の機械語命令列の実行終了アドレスが必要だからである。 前記実行終了アドレスが分かれば、前記開始アドレスに到達した時点で代替関数の機械語命令列を実行し、前記終了アドレスの機械語命令実行後のアドレスに無条件分岐するようなパッチデータを生成すれば良いのであるが、前記終了アドレスを特定をすることが困難と考えられる場合、この事実を表示装置３を介して使用者に伝えることが望ましい。 尚、本実施例のデバッグ情報であるＤＷＡＲＦ形式は、「．ｄｅｂｕｇ＿ｆｒａｍｅ」と名付けられたセクションにあるコールフレーム情報によって実行終了アドレスを取得できる場合がある。

また、前述した関数の名称をキーとした既存関数の探索では、複数の既存関数と遭遇することも十分に考えられる。 この原因としては、既存関数がインライン展開されており、デバッグ対象の機械語命令列２３においてインライン展開された１つ以上の箇所で条件一致する場合と、デバッグ対象のソースプログラムにおいて、型属性「ｓｔａｔｉｃ」を伴って条件一致する関数が１つ以上の箇所で記述されている場合の２つがある。

前記インライン展開が行われている場合、対象となる関数はタグ「ＤＷ＿ＴＡＧ＿ｉｎｌｉｎｅｄ＿ｓｕｂｒｏｕｔｉｎｅ」によって識別が可能である。 また、前記識別子「ｓｔａｔｉｃ」を伴っている場合、タグ「ＤＷ＿ＴＡＧ＿ｓｕｂｐｒｏｇｒａｍ」の属性「ＤＷ＿ＡＴ＿ｅｘｔｅｒｎａｌ」が無いもしくはフラグ値０を持った形で記述されるので、これを基に識別が可能である。

前述した複数の既存関数がある場合、デバッグ対象のソースプログラムにおいて条件一致した箇所を関数差し替え箇所の候補として表示装置３を介して使用者に知らせ、使用者がこれを選択出来ることが望ましい。

前述したような、様々な情報を表示装置３を介して使用者に知らせ、最終的な処理実行の可否は使用者が決定する。

このような本実施例によれば、デバッグ対象の機械語命令列に含まれる既存関数の実体である機械語命令列が、前述した標準呼出規則に準拠していれば、検査ソースプログラムに含まれる代替関数との差し替えを行うことが出来る。 本実施例は、実施例１よりもデバッグ情報の信頼性への依存度が低く、検査ソースプログラムの記述についての自由度も高い。更に、予めデバッグ対象のソースプログラムに記述されている既存関数の「名称」と「引数の型」と「戻り値の型」を使用者が把握している場合、デバッグ対象のソースプログラムそのものが必要ないという特徴もある。しかし、同一の検査ルーチンを挿入する場合、実施例１よりも生成されるパッチデータのサイズが大きくなる。

プログラムのパッチデータ生成装置１のブロック図 本発明の実施例における、デバッグ対象のソースプログラムと、デバッグ情報が持つ行番号プログラムの実行結果を示す図 デバッグ対象の、ソースプログラムと機械語命令列の混在表記図 本発明の実施例における、検査ソースプログラムを挿入するイメージ図 本発明の実施例における、検査ソースプログラムの入力及び挿入箇所指示の図 本発明の実施例における、関数の引数及び戻り値の受け渡し規則を示す図 本発明の実施例における、既存関数ｆｕｎｃ１のデバッグ情報の解析結果の図 本発明の実施例における、既存関数ｆｕｎｃ１のデバッグ情報の解析結果の図 本発明の実施例における、既存関数ｌｏｇｏｕｔのデバッグ情報の解析結果の図 本発明の実施例における、検査ルーチン生成部が生成及び追記する機械語命令列を示す図 プログラムのパッチデータ生成装置１００のブロック図 本発明の実施例における、代替関数ｆｕｎｃ１のソースプログラムを示す図 本発明の実施例における、代替関数ｆｕｎｃ１の入力を示す図 本発明の実施例における、既存関数差し替え部が生成する代替関数ｆｕｎｃ１の機械語命令列の図

符号の説明

１、１００ プログラムのパッチデータ生成装置
１１、１１０ コマンド解析部
１２、１２０ 検査ソースプログラム管理部
１３ 検査ルーチン挿入位置指定部
１４、１４０ デバッグ情報管理部
１５ 検査ルーチン生成部
１５０ 既存関数差し替え部
２ 記憶装置
２１ デバッグ対象のソースプログラム
２２ デバッグ情報
２３ デバッグ対象の機械語命令列
２４ 検査ソースプログラム
２５ パッチデータ
３ 表示装置
４ 入力装置
５ デバッグ対象の、ソースプログラム及び機械語命令列の混在表記図
５０、５１、５２、５３、５４、５５、５６、５７ ブレークポイントに属するデバッグ対象のソースプログラム
５０１、５１１、５２１、５３１、５４１、５５１、５６１、５７１ ブレークポイントに属するデバッグ対象の機械語命令列
５０２、５３２ プロローグ・ブレークポイント
５２２、５７２ エピローグ・ブレークポイント
５１２、５４２、５５２、５６２ ブレークポイント
５５１０ レジスタＲ０を書き換える機械語命令
６ 関数の引数及び戻り値の受け渡し規則（Ｔｈｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ Ｓｔａｎｄａｒｄ）の一部
７ 関数ｆｕｎｃ１のデバッグ情報エントリの解析結果
７０、７１、７２、７３、７４ タグ
７００、７０１、７０２、７０３、７０４、７０５、７０６、７０７ タグ７０の属性
７１０、７１１、７１２、７１３、７１４ タグ７１の属性
７２０、７２１、７２２、７２３、７２４ タグ７２の属性
７３０、７３１ タグ７３の属性
７３２ タグ７３に属するタグ
７３２２、７３２３、７３２４、７３２５、７３２６ タグ７３２に属するタグ
７３２２０、７３２２１、７３２２２、７３２２３、７３２２４ タグ７３２２の属性
７３２３０、７３２３１、７３２３２、７３２３３、７３２３４ タグ７２２３の属性
７３２４０、７３２４１、７３２４２、７３２４３、７３２４４ タグ７３２４の属性
７３２５０、７３２５１、７３２５２、７３２５３、７３２５４ タグ７３２５の属性
７３２６０、７３２６２、７３２６３、７３２６４、７３２６５、７３２６６ タグ７３２６の属性
７３２６１ タグ７３２６に属するタグ
７４０、７４１、７４２、７４３、７４４ タグ７４の属性
８ 関数ｌｏｇｏｕｔのデバッグ情報エントリの解析結果
８０、８１ タグ
８００、８０１、８０２、８０３、８０４、８０５、８０６、８０７ タグ８０の属性
８１０、８１１、８１２、８１３、８１４、８１５、８１６ タグ８１の属性

Claims (6)

1. デバッグ対象のソースプログラムをコンパイルリンクして得られるデバッグ対象の機械語命令列と、前記コンパイルリンクによって得られるデバッグ情報を入力し、前記デバッグ対象のソースプログラムの任意に記述された関数の呼出と、前記デバッグ対象のソースプログラムの任意に記述された変数の利用を含む、高級言語で記述された検査ソースプログラムの挿入指示に従って、前記デバッグ対象のソースプログラムを再度コンパイルリンクすることなく、前記デバッグ対象の機械語命令列に適用可能な、機械語命令列からなる検査ルーチンのパッチデータを生成することを特徴とする、プログラムのパッチデータ生成装置。
2. 前記検査ソースプログラム内で、前記デバッグ対象のソースプログラムの任意に記述された関数と同じ、名称と、引数型と、戻り値型と、を持つ代替関数を記述することで、前記デバッグ対象のソースプログラムの任意に記述された関数を、前記代替関数に差し替える効果を持つパッチデータを生成することを特徴とする、請求項１記載のプログラムのパッチデータ生成装置。
3. 前記デバッグ情報が、前記デバッグ対象のソースプログラムの部分集合の先頭行と前記デバッグ対象の機械語命令列の特定アドレスの位置関係を示すブレークポイントと、前記関数の引数の個数と、前記関数の引数の型と、前記関数の戻り値の型と、前記関数の実体である機械語命令列が配置されるターゲットメモリのアドレス範囲と、前記変数の型と、前記変数が配置されるターゲットＣＰＵのレジスタと、前記変数が配置されるターゲットメモリのアドレス範囲と、を情報として備えることを特徴とする、請求項１及至２記載のプログラムのパッチデータ生成装置。
4. 前記デバッグ情報から、前記変数が配置されるターゲットＣＰＵのレジスタと、前記変数が配置されるターゲットメモリのアドレス範囲と、を求めるとき、前記デバッグ対象の機械語命令列をターゲットシステム上で実行することなく、前記関数の機械語命令列が置かれているターゲットメモリのアドレスをターゲットＣＰＵのプログラムカウンタの値として用いることを特徴とする、請求項１及至３記載のプログラムのパッチデータ生成装置。
5. 前記デバッグ対象のソースプログラムと、前記検査ソースプログラムに用いる前記高級言語が、Ｃ言語であることを特徴とする、請求項１及至４記載のプログラムのパッチデータ生成装置。
6. 前記デバッグ情報がＤＷＡＲＦ２及びＤＷＡＲＦ３形式であることを特徴とする、請求項１及至５記載のプログラムのパッチデータ生成装置。

Images