JPH0950389A - コンピュータシステムを使って実装される装置及び方法 - Google Patents

Abstract

(57)【要約】 【課題】大きいプログラムに対しても実用性があり、手
作業によるインストルメンテーションのような柔軟性が
あるようなインストルメンテーションを提供する。 【解決手段】本発明の第１プログラムの動的特性につい
ての情報を得るための技術は、 所望の情報を作るのに
いかなるインストルメンテーションが必要とされるのか
を決定する第１のプログラムの静的な解析をする。 プ
ログラマブルインストルメンテーション装置が第１のプ
ログラムのインストルメントされたバージョンを作るよ
うに、第２プログラムを作る。インストルメントされた
プログラムの実行により、動的特性の情報が提供され
る。インストルメンテーション装置のためのプログラム
は、ソースコードを静的に解析するソースコードアナラ
イザによって作られる。ソースコードアナライザは従っ
て、コードアナライザジェネレータによって作られる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェアのテ
スト及び検証に関し、特に、プログラムの動的特性（ダ
イナミックプロパティ）の決定に関する。

【０００２】

【従来の技術】大きなプログラムの開発の際には、動的
特性の知識を有することは重要である。これは、プログ
ラムを動かすことのみによって決められる特性である。
動的特性はプログラムの正規運転のときには隠れてしま
う情報をしばしば伴う。プログラムＰ及びプログラムの
入力Ｉの組に関するこのような動的特性の例としては以
下のようなものがある。 １．入力Ｉで動くとき、Ｐはその全ての関数を実行する
か？ ２．入力Ｉで動くとき、Ｐが両方の方向でその全てのｉ
ｆ文を実行するか？ ３．入力Ｉで動くとき、struct person* のタイプのポ
インタ変数 aPerson が、struct person 型ではないオ
ブジェクトをポイントすることは起きるか？ 上記の情報と同様な他の情報を外部から見えるようにす
るために、プログラムは、実行したときに所望の情報を
有する出力を作るように、何らかの方法でインストルメ
ントする必要がある。

【０００３】従来の技術は、プログラムをインストルメ
ントする多くの方法を発展させた。これらの１つの方法
は、プログラムを構築するプロセスのときにインストル
メンテーションを加える。即ち、オブジェクトコードを
作るためにソースコードを編集するプロセスにおいてで
ある。この方法に属する１つとしては、ソースコードに
インストルメンテーションのためのコードを単に加え
て、次にオブジェクトコードを作るためにソースコード
をコンパイルする方法がある。ここで、オブジェクトコ
ードはもちろん、ソースコードに加えられたインストル
メンテーションコードに対応するコードを含有してい
る。別の方法としては、必要なインストルメンテーショ
ンをオブジェクトコードに加える特別なコンパイラを使
ってソースコードをコンパイルすることがある。

【０００４】最初の技術であるソースコードにインスト
ルメンテーションコードを加える方法は非常に一般的で
ある。加えることができるインストルメンテーションの
タイプは、プログラマの創意によって数多くある。不利
なこととしてはもちろん、インストルメンテーションを
加えることはソースコードを変えることを意味すること
である。従って、調査されるソースコードはもう元のソ
ースコードではない。２番目の技術は、ソースコードを
変えることを要しないが、あまり一般的ではない。特定
の特別なコンパイラによって提供されるインストルメン
テーションのみが加えられる。他のタイプのインストル
メンテーションは、他の特別なコンパイラ、あるいは現
存する特別なコンパイラの変更をも必要とする。このよ
うな特別なコンパイラの例としては、周知のＵＮＩＸオ
ペレーティングシステム（ＵＮＩＸはＸＯＰＥＮの登録
商標）の下で動作するコンピュータシステム上で利用可
能な lcc 又は cc -p がある。

【０００５】構築するときにプログラムをインストルメ
ントする技術の全ては、構築プロセスが非常に複雑にな
るので難しく、構築プロセスによって構築されたインス
トルメントされたバージョンのプログラムが、構築プロ
セスによって顧客のために構築するバージョンと機能上
等しいことを保証することは難しい。

【０００６】別の種類の技術は、プログラムが構築され
た後、プログラムのオブジェクトコードをインストルメ
ントするツールを使う。このようなものの例としては、
ピュアソフトウェア社（Pure Software, Inc.：米国カ
リフォルニア州サニーベール、Ｓ・メアリー通り１３０
９（1309 S. Mary Ave., Sunnyvale, CA.））によって
販売されている、ＰＵＲＩＦＹがある。これは機械語シ
ーケンスの特別なパターン及びコンパイラコード生成技
術を利用して、調査される特性にとって適切なバイナリ
コードにおける位置を識別する。ＰＵＲＩＦＹのような
ツールの不利な点は、ツールには異なる各種類に対する
プロセッサのバージョンを必要とするので、各ツールが
小さい固定された特性の集合の調査を許し、ポータビリ
ティがないということである。

【０００７】図１は、上述のタイプのシステムの概観で
ある。通常の状況の下では、１以上のプログラムのシス
テム１０２は入力１０１で実行環境１０４において動作
する。これらの条件の下では、例えば「このシステムは
入力１０１に対する全ての関数を実行するか」のような
内部の特性は決定できない。このような内部の特性を決
めるために、我々はシステム１０５の変換されたバージ
ョンを構築し、これは、所望の特性に適切なシステム１
０２の実行の際に何かが起きるときに副作用を生成する
ようにインストルメントされる。

【０００８】例えば、システム１０２が入力１０１で実
行されるときにその関数全てを実行するかどうかわかる
ことを望むならば、システム１０２によって呼び出され
た各関数のソースコードの始めにｐｒｉｎｔ文を挿入す
ることによってシステム１０２をインストルメントでき
る。このインストルメンテーションによりシステム１０
２をシステム１０５に変換する。ここで、この変換され
たシステム１０５は入力１０１で動くとする。変換され
たシステム１０５は、関数を実行するたびに、関数の始
めに挿入されたｐｒｉｎｔ文を実行する。ｐｒｉｎｔ文
の実行は副作用１０６であり、ｐｒｉｎｔ文の出力を見
ることによって、プログラマはどのｐｒｉｎｔ文が実行
されたかを決定でき、その情報を使ってどの関数が実行
されたかを判断できる。

【０００９】図４には、与えられたテスト入力の組に対
するテスト適用範囲（テストカバレージ）を決めるため
にソースコードが変更する方法の例が示される。この場
合、テストにより全てのｉｆ文にその真の枝と偽の枝両
方を実行させたかどうか決めることが目標である。ｉｆ
文を有する元のソースコード４０１（真、偽の枝がそれ
ぞれ行２、５にある）は、行１．ｉと４．ｉのｐｒｉｎ
ｔ文（４０２）を挿入されて変更される。この変更コー
ドが実行されると、枝の実行に対するメッセージがログ
ファイルに出力され、テスト適用範囲はログファイルの
メッセージを見ることによって決定できる。

【００１０】

【発明が解決しようとする課題】上記の技術は全て重要
な欠点を有する。手作業によるインストルメンテーショ
ンは完全な柔軟性があり、プログラマの創意によっての
み限定されるが、大きいプログラムに対しては非実用的
である。インストルメンテーションツールは大きいプロ
グラムに対して実用的であるが、各ツールはインストル
メンテーションの可能性の一部しか提供せず、結果的
に、これらのツールでされたインストルメンテーション
は手作業によるインストルメンテーションよりはるかに
柔軟性がないものである。本発明は、大きいプログラム
に対しても実用性があり、手作業によるインストルメン
テーションのような柔軟性があるようなインストルメン
テーションを提供する。

【００１１】

【課題を解決するための手段】本発明は、インストルメ
ントされるプログラムのソースコードを解析し、インス
トルメンテーション命令のシーケンスを生成するために
静的アナライザを使うことによって、従来技術の問題を
解決する。インストルメンテーション命令のシーケンス
は次に、インストルメンテーション命令で指定されるよ
うにコードをインストルメントする別のプログラムによ
って消費される。インストルメントされたコードは次
に、所望の情報を得るように実行される。静的アナライ
ザの使用は、今まで手作業によるインストルメンテーシ
ョンでだけ得られた柔軟性を可能にし、同時にいかなる
大きさのプログラムのインストルメンテーションを可能
にする。

【００１２】上記の発明の１つにおいては、デバッガの
ようなプログラマブル実行環境をプログラムするために
インストルメンテーション命令を使う。調査中のプログ
ラムの未修正コードは次に、プログラムされた実行環境
で実行され、この実行環境は、関心事の動的特性の情報
を出力することによって調査中のプログラムの実行に応
答する。

【００１３】別の発明においては、インストルメンテー
ション命令はバイナリ編集ツールをプログラムするため
に使われ、このツールはインストルメンテーションのオ
ブジェクトコードを含有するようにオブジェクトコード
を編集することによってプログラムに応答する。この編
集されたオブジェクトコードは、実行すると、関心事の
情報を出力する。

【００１４】第３の種類の発明においては、インストル
メンテーション命令はプログラマブル編集ツールをプロ
グラムするために使われる。プログラマブル編集ツール
は次に、インストルメンテーションのコードを含有する
ようにソースコードを変更することによってプログラム
に応答する。ソースコードがコンパイルされ、通常の方
法で実行されると、この実行により関心事の情報が出力
される。

【００１５】

【発明の実施の形態】以下においては、最初に本発明の
概観を示し、プログラマブルデバッガをプログラマブル
実行環境として用いて好ましい実施例を記述する。ま
た、プログラマブルデバッガに対するコードを作るため
にどのように静的ソースコードアナライザが使われる
か、及びどのようにこのような静的ソースコードアナラ
イザがコードアナライザを生成するシステムを用いて作
られるかを開示する。最後に、プログラマブルデバッガ
からの副作用が、テストされるプログラムの流れグラフ
のグラフ表示を駆動する一実施例を開示する。

【００１６】本発明の概観：図２ 図２には、プログラムの動的特性を調査する本発明の技
術を示す。システム２０２は、プログラマブル実行環境
２０３で実行される１以上のプログラムから構成されて
いる。このような実行環境の１つの例としては、プログ
ラマブルデバッガがある。我々はシステム２０２が入力
２０１で実行されるときに示す動的特性２０７のいくら
かに興味を持った。図１のようにシステムを変換する代
わりに、我々はシステム２０２を変えずに、システム２
０２が便利さのみのために図２で別に示したシステム２
０４と全く同じくなり、また、代わりに実行環境２０３
を他の実行環境２０５に変換するようにする。変換する
方法は、解析されるシステム（２０２≡２０４）及び動
的特性２０７の双方に依存する。変換された実行環境２
０５は、特性及びシステム自身によって決められるポイ
ントで、システム２０４（≡２０２）のプログラムの実
行に割り込み、副作用２０６を生成する。これらの副作
用は、図１で生成した副作用１０６のように、特性２０
７を調査するために使える。

【００１７】実施例：図３ 図３には、前段で記述したように実行環境を変更するこ
とによって動的特性を調査する方法の一実施例を示す。
図３では、実行環境２０３はデバッガ１０６である。デ
バッガとは、プログラム中のバグを発見するためにプロ
グラマが使うツールである。プログラムは、デバッグさ
れると、デバッガにおいて実行される。デバッガはプロ
グラマがプログラムの実行を精密に制御することを可能
にする。デバッガの基本的な能力としては、ブレイクポ
イントの設定がある。ブレイクポイントは、プログラム
がデバッガで実行されるときに、制御がプログラムから
デバッガへ渡されるプログラム中の位置のことである。
多くのデバッガはプログラム可能（プログラマブル）で
あり、即ち、プログラマはブレイクポイントの位置だけ
ではなく、ブレークポイントに遭遇したときの動作も指
定する命令のリストをデバッガに提供できる。動作とし
ては、デバッガを使っている人が再開するまで実行を止
めることや、機械レジスタの内容やメモリ位置をプリン
トアウトすることがある。

【００１８】本発明で使われるデバッガは、プログラム
の実行可能（エグゼキュタブル）バイナリと共に働く。
デバッガを使うプログラマは、プログラムのソースコー
ドに対してブレークポイントの位置を指定する。デバッ
ガは次に、実行可能バイナリコード中の対応する位置を
見つけ、実行可能バイナリ中のその点の命令を不当命令
（イリーガル・インストラクション）で置き換える。デ
バッガは、置き換えた命令及びデバッガがブレイクポイ
ントにおいてとる動作を保持する。

【００１９】プログラムが実行され、ブレークポイント
をセットしたポイントに到達したときに、ハードウェア
は不当命令に不当命令イベントで応答する。デバッガ
は、不当命令イベントに応答して、プログラマがブレー
クポイントに対して指定した動作を実行する。それがさ
れるとデバッガは、不当命令を保持された実際の命令で
置き換え、その命令を実行し、プログラムに制御を戻
し、次のブレイクポイントに到達するまで実行し続け
る。

【００２０】本発明の一実施例では、このようなデバッ
ガ３０６は、入力３０３で動くシステム３０２の特定の
特性３０８を決めるために使われる。最初に、静的アナ
ライザ３０４が特定の特性のために作られる。静的アナ
ライザ３０４は、システムのソースコード３０１に課さ
れ、デバッガ３０６に対してコマンド３０５のシーケン
スを生成する。ここで、システム３０２はデバッガ３０
６にロードされ、このデバッガは次に、静的アナライザ
３０４によって生成したコマンド３０５を実行すること
によって自身を構成し、最後に入力３０３を使ってシス
テム３０２を実行する。生成コマンド３０５によって構
成されたように、デバッガ３０６は指定ポイントにおい
てシステム３０２の実行を中断し、副作用３０７を作る
（例えば、ログファイルへの実行の中断時のプログラム
の状態の情報を書き込む）。この副作用は次に、動的特
性３０１の情報のために解析される。

【００２１】図５には、このアプローチが使用される例
を示す。ここで、ソフトウェアテストの応用例を示し、
これは、テストの組が完全であるかを決めることが望ま
れる。即ち、全てのｉｆ文の真と偽の双方の枝のテスト
である。例えば、ソースコード５０１では、真と偽の枝
がそれぞれ行２と５で始まるようなｉｆ文が行１にあ
り、テストは両方の枝を実行しなくてはならない。好ま
しい実施例では、静的アナライザ３０４は、ソースコー
ドアナライザを生成するツールであるＧＥＮＯＡを用い
る。ＧＥＮＯＡは、ピー・デバンブ（P. Devanbu）著の
論文「ＧＥＮＯＡ−言語及びフロントエンドに依存しな
いソースコードアナライザジェネレータ（GENOA- A lan
guage and front-end independent source code analyz
er generator）」（Proceedings, Twelfth Internation
al Conference on Software Engineering、１９９２年
５月）に記述されている。ＧＥＮＯＡ７１０により作ら
れた静的アナライザ３０４は、プログラムのソースコー
ド５０１の構文解析ツリー表示上で動作する。

【００２２】構文解析ツリーは、ラベル付けされた端部
が接続されたラベル付けされた節の集合である。節は構
文解析ツリーの異なる部分を表す。節上のラベルは、こ
の節によって表される構文構造のタイプを表す。解析さ
れるプログラムを含む全ソースファイルは、Ｆｉｌｅと
ラベル付けされた節によって表される。この節より下の
ツリーでは、ｉｆ文６０１に対応するＩｆとラベル付け
された節がある。構文解析ツリーのこの部分は図６の符
号６０２に現われる。この節から出て行く２つの端があ
り、これらは、ｉｆ文６０１のｔｈｅｎ及びｅｌｓｅの
部分に対応するｔｈｅｎ及びｅｌｓｅ（英大文字で示し
てある）とラベル付けされている。これらの各端は、Ｉ
ｆ節（６０１の行１）を６０１の行２と５で始まるブロ
ックを表すＢｌｏｃｋ節に接続する。

【００２３】ＧＥＮＯＡ７１０によって作られた静的ア
ナライザ３０４は、ｉｆ文を表す節を探している構文解
析ツリーを横断する。アナライザは、Ｉｆ文の節を見つ
けると、構文解析ツリーからソースコードにおける真と
偽の枝に対する開始位置が何であるかを判断し、それら
の位置、及び到達されたときに行われる動作を指定する
デバッガコマンド５０２（図５）を生成する。コマンド
がデバッガ３０６に供給され、ソース５０１から構築さ
れたシステム３０２がそのコマンドによって構成される
ようにデバッガによって実行されると、デバッガは実行
によって到達した各ブレイクポイントにおいて、そのブ
レイクポイントに対して指定された動作を行う。もしブ
レイクポイント全てに対して指定した動作が起きたなら
ば、テストの組は、ｉｆ文の枝に関して完成したことに
なる。ここで、デバッガ命令は、ソース５０１から作ら
れる必要はなく、テストされるプログラムのいかなる使
用可能な情報源からも作られる。

【００２４】前述の議論から明白であるように、この技
術はソースコードの変更を要しない。デバッガによって
作られる実行可能バイナリの変更は、一時的であって、
実行可能バイナリへの命令の付加は伴わない。デバッガ
が多くのプラットホーム上に得られるものであるなら
ば、ポータビリティを犠牲にせずにバイナリインストル
メンテーションの便利さを得られる。このようなデバッ
ガの例としてｇｄｂがあり、これは、prep.mit.eduから
のインターネットのファイル転送によって得られるアー
ル・ストールマン（R. Stallman）とアール・ペッシュ
（R. Pesch）著の「ＧＤＢを用いてのデバッグ（Debugg
ing with GDB）」に記述されている。

【００２５】動的特性アナライザをグラフ表示にする：
図７ デバッガ３０６によって作られる副作用３０７はもちろ
ん、動的特性を解析することに役立つ出力を作るいかな
る種類のデバイスへも提供される。例えば、図７では、
副作用３０７は流れグラフ７０５を動かすために使われ
る。流れグラフ７０５は、ＧＥＮＯＡで作られた別の静
的アナライザ７０９を使って作られる。流れグラフ７０
５は、視覚表示のためにグラフブラウザ７０６に提供さ
れる。次に、我々は、上述のようにデバッガ７０４のた
めにコマンド７０３を作るためにソースコードを解析す
る。コマンドは、ブロック等の初めにブレークポイント
をセットする。即ち、ブレークポイントが始動するたび
に、デバッガはコマンドが指定するように応答する。こ
の場合、このコマンドは、流れグラフの視覚表示の変更
を指定するプロセス間メッセージ７０８が、デバッガ７
０４が実行しているプロセスからグラフブラウザ７０６
が実行しているプロセスまで送られることを指定する。
このメッセージに応答して、グラフブラウザ７０６は視
覚表示を変更する。この技術はテスト適用範囲情報の視
覚表示のため、又はプログラム理解やデバッグの単なる
手助けとして用いられる。

【００２６】静的アナライザを作るためにＧＥＮＯＡを
使う：図８ 静的アナライザ３０４を作るためにＧＥＮＯＡ７１０で
使われる指定８０９の一部が図８で示される。ＧＥＮＯ
Ａが指定８０９から作る静的アナライザは、全体のプロ
グラムのブロックとｓｗｉｔｃｈ文の検索を行う。この
検索は、行８０１と行８０７の終わりにおいて角括弧
（［、］）によって指定される。何を検索するかが行８
０２（ブロックに対して）及び行８０４（ｓｗｉｔｃｈ
文に対して）指定される。行８０３は、ブレークポイン
トがブロックの始めにセットされ、ブレイクポイントを
削除し、継続するようにデバッガに指示する各ブレーク
ポイントに対してデバッガコマンドを生成すべきである
ことを指定する。ｓｗｉｔｃｈ文に対しては、ブレイク
ポイントはｓｗｉｔｃｈの各ｃａｓｅにセットされ（行
８０７）、同じデバッガコマンドが生成される。各ブレ
イクポイントは始動されると削除されるので、テストラ
ンの後に残るブレイクポイントは、実行されなかったコ
ードの部分を指示する。好ましい実施例で採用するプロ
グラマブルデバッガは、ユーザにいずれのブレークポイ
ントが実行されなかったかを示し、従っていずれのコー
ドの部分が実行されなかったかを示す。ＧＥＮＯＡ７１
０及びそれが静的コードアナライザを指定するために用
いる言語のより詳細な記述としては、前記のデバンブ・
ピー著の論文「ＧＥＮＯＡ−言語及びフロントエンドに
依存しないソースコードアナライザジェネレータ」を参
照するとよい。

【００２７】図８から明白であるように、ＧＥＮＯＡ７
１０のような静的ソースコードアナライザジェネレータ
の使用は大いに静的アナライザ３０４の実装を単純化す
る。ＧＥＮＯＡのようなツールが、ｇｄｂのようなポー
タブルなプログラマブルデバッガと使われると、広範囲
のハードウェア上の広範囲の動的特性を決める装置を容
易に実装することができる。

【００２８】コードをインストルメントするために静的
アナライザとバイナリ編集ツールを使う：図９及び１０ 前述のインストルメンテーション技術は柔軟性があり、
ポータブルである。しかしながら、デバッガを使うこと
に対してペナルティーがある。インストルメントされた
コードがデバッガの制御下で実行され、実行がインスト
ルメントされたポイントに到達すると、デバッガはイン
ストルメンテーションで指定した情報を集めるために呼
び出されなければならず、これをした後は、デバッガは
目的プログラムに戻らなくてはならない。これは、イン
ストルメントされたポイントに到達するたびに、２つの
文脈を切り替え、これは従って望ましくない程度まで目
的プログラムの実行の速度を遅くする。

【００２９】文脈切り替えのオーバーヘッドを避けるた
め、我々はインストルメンテーションを提供するために
デバッガの代わりにプログラマブルバイナリ編集ツール
を使う技術を開発した。プログラマブルバイナリ編集ツ
ールは、プログラムのオブジェクトコードを編集し、結
果的にオブジェクトコードをインストルメントするため
に使われる。インストルメンテーションがオブジェクト
コードに含まれているので、インストルメントされたポ
イントに到達するときにはいつでも、文脈を切り替える
必要はない。プログラマブルバイナリ編集ツールは最近
多くのハードウェアプラットホームにおいて利用可能に
なった。それらは実行可能プログラムを走り読み、解
析、変更することに対して様々な基本を提供する。この
ようなツールの典型的な応用例としては、バイナリを走
り読みし、全てのロード及び格納命令においてインスト
ルメンテーションを挿入して、そのロード又は格納がキ
ャッシュのミスをもたらすかどうか調べる。このような
ツールは使用が難しく、プラットフォームに大きく依存
するが、高効率な動的にインストルメントされたバイナ
リをもたらす。このような編集ツールの例としては、Ａ
ＴＯＭがある。（エー・スリバスタバ（A. Srivastav
a）及びエー・ユーステース（A. Eustace）共著の論
文、「ＡＴＯＭ；カスタマイズ可能なプログラム解析ツ
ールを構築するシステム」（Proceedings of the ACM S
IGPLAN Conference on Programming Language Design a
nd Implementation、米国フロリダ州オーランド、１９
９４年）を参照するとよい。）

【００３０】バイナリ編集ツールを使うプログラムをイ
ンストルメントする本発明の技術は、前と同様にソース
コードを静的に解析して動作時において介入が必要であ
るソースコードにおけるポイントを決定する。しかしな
がら、デバッガのためにコマンドを生成する代わりに、
我々はバイナリインストルメンテーションプログラムの
ためにコマンドを生成する。我々はＡＴＯＭでこの技術
を使い、ＡＬＰＨＡ（商標）プラットホームの枝適用範
囲解析ツールを作った。

【００３１】図９には、上記の技術の好ましい実施例を
示す。インストルメンテーションシステム９０１はＡＴ
ＯＭシステム９１１を採用した。ＡＴＯＭは、デジタル
・イクイップメント・コーポレーション（米国マサチュ
ーセッツ州メイナード）のＡＴＯＭリファレンスマニュ
アル（１９９３）で完全に記述されている。これは、イ
ンターネットのftp://ftp.dec.com/pub/DEC/atomtools
から入手可能である。

【００３２】図９で示すように、ＡＴＯＭを使ってシス
テムをインストルメントするためには、ソースコード９
０３をコンパイラとリンカ９０５を使って従来の方法コ
ンパイル、リンクする。このプロセスの結果として、シ
ステムのためにオブジェクト又はバイナリコードファイ
ル９０６がもたらされる。次のステップは、インストル
メントされたバイナリコードファイル９１３を作るため
にバイナリコードファイル９０６にＡＴＯＭ９１１を課
すことである。ＡＴＯＭ９１１がバイナリコードファイ
ル９０６をインストルメントする方法は、ファイル９０
９によって決められる。このようなファイルには３種類
あり、解析コード９１７は周知のＣ言語の１以上の関数
を含み、これは、プログラムの実行についてのデータを
収集し、出力する。インストルメンテーションコード９
１９は、解析コード９１７で指定された関数がインスト
ルメントされたバイナリファイル９１３内のコードの実
行の間に呼び出されるときに指定する関数を含む。イン
ストルメンテーションコード９１９内の関数は従って、
ヘッダーファイル９１５内のデータから解析関数が呼び
出されるときに決める。例えば、ヘッダーファイル９１
５が解析コード９１１内の与えられた関数が呼び出され
る命令のソースコードにおける行番号をリストするファ
イルを有し、インストルメンテーションコード９１９
は、プログラム実行がヘッダーファイル９１５で指定さ
れた行番号の１つに到達すれば必ず与えられた関数が呼
び出されることを指定する関数を有する。

【００３３】ＡＴＯＭは、ファイル９０９のコードとデ
ータ、及びコンパイラとリンカ９０５によって作られる
バイナリコードファイルをとり、それらからインストル
メントされたバイナリファイル９１３を作る。これらの
インストルメントされたファイル９１３は、解析コード
９１７で指定された関数への呼出しのオブジェクトコー
ドがインストルメンテーションコード９１９及び適切な
らばヘッダファイル９１５で指定する位置でインストル
メントされたバイナリファイル９１３に挿入されている
という点で、オリジナルバイナリファイル９０６と相違
する。さらに、解析コード９１７の関数のオブジェクト
コードはインストルメントされたバイナリ９１３の中へ
とリンクされる。従って、インストルメントされたバイ
ナリファイル９１３が実行されると、解析コード９１１
の関数への呼出しは、インストルメンテーションコード
９１９、９１５で指定されるように呼び出され、呼び出
された関数により作られたデータは、インストルメント
されたバイナリファイル９１３が実行されると、出力さ
れる。データはファイルにただ出力するか、又はユーザ
の必要に応じて用いる。例えば、そのデータは、図７の
デバッガ７０４からのデータの出力に関して記述したよ
うに、グラフブラウザを駆動するために使うことができ
る。さらに、解析関数がインストルメントされたバイナ
リ９１３の中へとリンクされるので、呼出しと戻しは、
プログラマブルデバッガが用いられるときにインストル
メントするコードの実行を遅くする文脈変更無しでされ
る。

【００３４】前述の記載からわかるように、ＡＴＯＭは
非常に柔軟性がある。解析コードの唯一の限界は、Ｃ言
語のものであり、ヘッダーファイルとインストルメンテ
ーションコードの双方は命令、ブロックとプロシージャ
のレベルにおいてインストルメンテーションを許す。大
きいプログラムでのＡＴＯＭの使用はしかしながら、フ
ァイル９０９の内容が手作業により作られ、これらのフ
ァイルの中のプログラムは、大きく、複雑で、書くこと
が難しいので限定される。それらは、インストルメント
されるプログラムに特殊なことではない。

【００３５】これらの欠点は、静的アナライザ９０１を
使ってファイル９０９の内容の部分又は全てを作ること
で克服できる。静的アナライザ９０７は、静的アナライ
ザ８０７がデバッガコマンドの代わりに、ヘッダーファ
イル９１５、解析コード９１７、又はインストルメンテ
ーションコード９１９のデータの全て又は部分を生成す
る。ヘッダファイル９１５の内容がインストルメントさ
れたバイナリ９１３のふるまいを制御するので、ヘッダ
ーファイル９１５、及び解析コード９１７とインストル
メンテーションコード９１９のコードの間には概念的に
差がない。また、静的アナライザ９０７は手作業により
構築でき、又はＧＥＮＯＡ７１０のようなジェネレータ
ツールを使って作られる。

【００３６】適用範囲解析を許すためにインストルメン
トされたプログラムの例と同じことはプログラマブルデ
バッガの代わりにＡＴＯＭを使ってされる。図１０に
は、このような例のファイル９０９の内容の断片を示
す。１００３には、インストルメントされるべきコード
を含むソースコードファイルｘ．ｃの断片を示し、この
断片には、ｉｆ．．．ｅｌｓｅ文が示されている。我々
がこのプログラムのテストが完全にこのプログラムをカ
バーするか知りたいので、我々は行１０２の文が実行さ
れたときに第１の副作用が発生し、行１０６の文が実行
されたときに第２の副作用が発生するように、断片をイ
ンストルメントする必要がある。

【００３７】この場合に必要とする解析関数は単純であ
る。インストルメントされている行が実際に実行された
ことを指示する情報を出力するだけでよい。この解析コ
ードの断片が１００５で示してある。インストルメンテ
ーションコード９１９もまた単純である。ヘッダファイ
ル９１５の１つで指定された行が実行されたとき、解析
関数は呼び出されることを指定するだけでよい。コード
９１９の断片が１００９で示してある。ヘッダファイル
９１５の断片が最後に、１００７で示してある。ここで
見られるように、ヘッダーファイルは、各エントリーが
ソースコードファイル名（ここでは、ｘ．ｃ）及びイン
ストルメントされるそのソースコードファイルの行数を
含むリストである。

【００３８】我々の例では、解析関数とインストルメン
テーション関数のコードは、手作業によって書かれるほ
ど単純で、一般的である。静的アナライザ９０７は、枝
の全てが実行されることを確実にするためにｘ．ｃのい
ずれの行がインストルメントされるか指示するヘッダフ
ァイル９１５を生成するために使われる。静的アナライ
ザ９０１がヘッダーファイル９１５を生成する方法はも
ちろん、デバッガコマンドを生成した方法と比べて正確
に同じである。出力はデバッガコマンドのために必要と
される形式よりむしろヘッダーファイルのために必要と
される形式である。

【００３９】結論 前述の記載により、プログラムの動的特性を決める最も
良い態様を開示した。これらの技術の重要な点は、プロ
グラムインストルメンテーションをするためにプログラ
マブルデバイスに命令を生成するために静的解析を使用
することである。ここに開示したように、プログラマブ
ルデバイスは、プログラマブルデバッガ又はプログラマ
ブルバイナリエディタである。しかしながら、本発明の
技術は他のデバイスで用いられてもよい。例えば、プロ
グラマブルデバイスはプログラムソースコードのための
プログラマブルエディタである。インストルメンテーシ
ョンの指定の命令を生成するための静的解析の使用は、
プログラムをインストルメントする人に、手作業による
インストルメンテーションに柔軟性を与えるが、いかな
る大きさのプログラムに対して容易なインストルメンテ
ーションを可能にする。最後に、ＧＥＮＯＡのようなシ
ステムを使って静的アナライザを作ることは特に有利で
あるが、アナライザは手作業による方法を含むいかなる
方法ででも作ることができる。

【００４０】

【発明の効果】以上述べたように、本発明の第１プログ
ラムの動的特性についての情報を得るための技術は、
所望の情報を作るのにいかなるインストルメンテーショ
ンが必要とされるのかを決定する第１のプログラムの静
的な解析をする。 次に、プログラマブルインストルメ
ンテーション装置が第１のプログラムのインストルメン
トされたバージョンを作るように、第２プログラムを作
る。インストルメントされたプログラムの実行により、
動的特性の情報が提供される。インストルメンテーショ
ン装置のためのプログラムは、ソースコードを静的に解
析するソースコードアナライザによって作られる。ソー
スコードアナライザは従って、コードアナライザジェネ
レータによって作られる。インストルメンテーションか
らの出力は、グラフ表示システムに供給される。コード
アナライザジェネレータは、単に第２プログラムを作る
ためのソースコードアナライザを生成するだけではな
く、グラフブラウザによって実行されるとプログラムの
ために流れグラフを作るプログラムを作るためのソース
コードアナライザをも生成する。この場合、グラフブラ
ウザは、流れグラフの形を変えることによって実行環境
からの出力に応答する。これにより、大きいプログラム
に対しても実用性があり、手作業によるインストルメン
テーションのような柔軟性があるようなインストルメン
テーションが提供できる。

【図面の簡単な説明】

【図１】従来技術のプログラムの動的特性の決定を示す
概観ブロック図である。ここで本図面の符号は、２つの
部分を有し、下二桁は図の中のアイテムの番号であり、
残りの桁はアイテムが最初に現われる図の番号である。
従って、符号２０１のアイテムは図２に最初に現われ
る。

【図２】本発明のプログラムの動的特性の決定を示す概
観ブロック図である。

【図３】実行環境がデバッガである一実施例を示す概観
ブロック図である。

【図４】従来技術のプログラムの枝適用範囲特性を決め
るためのソースコードのインストルメントを示すソース
コードである。

【図５】本発明のプログラムの枝適用範囲特性の決定に
使われるように実行環境を変更する方法を示すソースコ
ードである。

【図６】プログラムの構文解析ツリーの静的解析が実行
環境の変更のコードを生成する方法を示すソースコード
とブロック図の混合図である。

【図７】実行環境からの出力が、プログラムのテスト結
果の動的なグラフ表示を作るようにどのようにグラフブ
ラウズプログラムに課されるかを示す概略ブロック図で
ある。

【図８】静的アナライザの生成に使われるＧＥＮＯＡ仕
様の一部のソースコードである。

【図９】従来の静的解析がコードをインストルメントす
るためにバイナリインストルメンテーションツールと関
連して使われる方法の概観ブロック図である。

【図１０】テスト適用範囲に対するインストルメンテー
ションに対して生成されたコード及びデータの例であ
る。

【符号の説明】

１０１ 入力 １０２ システム １０４ 実行環境 １０５ 変換されたシステム １０６ 副作用 １０７ 動的特性 ２０１ 入力 ２０２ システム ２０３ 実行環境 ２０４ システム ２０５ 変更された実行環境 ２０６ 副作用 ２０７ 動的特性 ３０１ ソースコード ３０２ システム ３０３ 入力 ３０４ 静的アナライザ ３０５ デバッガコマンド ３０６ デバッガ ３０７ 副作用 ３０８ 動的特性 ７０１ ソースファイル ７０２ 実行可能バイナリ ７０３ ブレークコマンド ７０４ デバッガ ７０５ 流れグラフ ７０６ グラフブラウザ ７０９ 流れグラフ静的アナライザ ７１０ アナライザジェネレータ ８０９ 指定 ９０１ インストルメンテーションシステム ９０３ システムのソースコード ９０５ コンパイラとリンカ ９０６ バイナリ ９０７ 静的アナライザ ９０９ ファイル ９１１ ＡＴＯＭ ９１３ インストルメントされたバイナリ ９０９ ファイル ９１５ ヘッダーファイル ９１７ 解析コード ９１９ インストルメンテーションコード

Claims (18)

【特許請求の範囲】
1. 【請求項１】該コンピュータシステム及び該装置にアク
   セスできる第１の実行可能プログラム（３０２）の動的
   特性についての第１の情報（３０８）を得るために使わ
   れるコンピュータシステムを使って実装される装置であ
   って、この装置が、 前記第１プログラムについての第２の情報（３０１）を
   静的に解析して、そこから第２プログラム（３０３）を
   作るための静的解析手段（３０４）であって、前記第２
   の情報が、該コンピュータシステムにアクセスでき、前
   記静的解析手段が、該コンピュータシステムで実行する
   ことと、及び該コンピュータシステムがインストルメン
   トされたプログラムを実行するときに、前記第１の情報
   が出力されるように、前記第２プログラムに応答して該
   コンピュータシステムで前記第１プログラムをインスト
   ルメントするための手段（３０６）とからなることを特
   徴とするコンピュータシステムを使って実装される装
   置。
2. 【請求項２】前記第１プログラムをインストルメントす
   る手段は、前記第１プログラムのバイナリをインストル
   メントすることによって前記第２プログラムに応答する
   バイナリエディタであることを特徴とする請求項１記載
   のコンピュータシステムを使って実装される装置。
3. 【請求項３】前記第１プログラムをインストルメントす
   る手段は、前記第１の情報が出力されるように、前記第
   ２プログラムの制御の下で前記第１プログラムを実行す
   るプログラマブルデバッガであることを特徴とする請求
   項１記載のコンピュータシステムを使って実装される装
   置。
4. 【請求項４】前記第２の情報は、前記第１プログラムに
   対するソースコードであることを特徴とする請求項１乃
   至３記載のコンピュータシステムを使って実装される装
   置。
5. 【請求項５】前記静的解析手段を自動的に生成する手段
   （７１０）からさらになり、この自動的に生成する手段
   が、前記第２の情報と及び前記第１の情報を得る技術の
   指定（８０９）とに応答し、 この指定が該コンピュータシステムにアクセスでき、 この自動的に生成する手段が該コンピュータシステムに
   おいて実行することを特徴とする請求項１乃至３記載の
   コンピュータシステムを使って実装される装置。
6. 【請求項６】前記第２の情報は、前記第１プログラムの
   ソースコードであることを特徴とする請求項５記載のコ
   ンピュータシステムを使って実装される装置。
7. 【請求項７】前記第１の情報に応答してグラフ表示を提
   供する手段とからさらになることを特徴とする請求項１
   乃至３記載のコンピュータシステムを使って実装される
   装置。
8. 【請求項８】前記グラフ表示は、前記第１プログラムの
   流れグラフであり、前記第１の情報に応答する手段は流
   れグラフを変更することを特徴とする請求項７記載のコ
   ンピュータシステムを使って実装される装置。
9. 【請求項９】該コンピュータシステムがアクセスできる
   第３プログラム（７０５）を作るように、前記第２の情
   報を静的に解析するコンピュータシステムで実行する第
   ２の手段（７０９）とからさらになり、 前記第１の情報に応答する前記手段は、前記第３プログ
   ラム１０の制御の下で前記第１プログラムの流れグラフ
   のグラフ表示を作ることを特徴とする請求項７記載のコ
   ンピュータシステムを使って実装される装置。
10. 【請求項１０】該コンピュータシステムにアクセスでき
    る第１の実行可能プログラムの動的特性についての第１
    の情報を得るためのコンピュータシステムを使って実装
    される方法であって、この方法が、 前記第１プログラムについての第２の情報を静的に解析
    することによって、該コンピュータシステムにアクセス
    できる第２プログラムを作るステップと、及び該コンピ
    ュータシステムが前記インストルメントされたプログラ
    ムを実行するときに該コンピュータシステムによって前
    記第１の情報が出力されるように、前記第１プログラム
    をインストルメントするために前記第２プログラムを使
    うステップとからなるコンピュータシステムを使って実
    装される方法。
11. 【請求項１１】前記第１プログラムをインストルメント
    するために前記第２プログラムを使う前記ステップは、
    前記第１プログラムのバイナリをインストルメントする
    ことによって前記第２プログラムに応答するバイナリエ
    ディタで実行されることを特徴とする請求項１０記載の
    方法。
12. 【請求項１２】前記第１プログラムをインストルメント
    するために前記第２プログラムを使う前記ステップは、
    前記第１の情報が出力されるように前記第２プログラム
    の制御の下で前記第１プログラムを実行するプログラマ
    ブルデバッガで実行されることを特徴とする請求項１０
    記載の方法。
13. 【請求項１３】第２プログラムを作る前記ステップは、
    前記第１プログラムのソースコードを前記第２の情報と
    して用いることを特徴とする請求項１０乃至１２記載の
    方法。
14. 【請求項１４】前記第２の情報を静的に解析するため
    に、第３プログラムを自動的に生成するステップとから
    さらになり、 自動的に生成する手段が、前記第２の情報と、及び前記
    第１の情報を得る技術の指定（８０９）に応答して生成
    し、 この指定が、該コンピュータシステムにアクセスでき、 前記第２プログラムを作る前記ステップは、前記第３プ
    ログラムを使ってされることを特徴とする請求項１０乃
    至１２記載の方法。
15. 【請求項１５】第２プログラムを作る前記ステップは、
    前記第１プログラムのソースコードを前記第２の情報と
    して使ってされることを特徴とする請求項１４記載の方
    法。
16. 【請求項１６】前記第１の情報のグラフ表示を作るステ
    ップとからさらになることを特徴とする請求項１０乃至
    １２記載の方法。
17. 【請求項１７】前記第１の情報のグラフ表示を作る前記
    ステップは、前記第１の情報に従って前記第１プログラ
    ムの流れグラフを作って、変えるステップを含むことを
    特徴とする請求項１６記載の方法。
18. 【請求項１８】流れグラフのグラフ表示をグラフブラウ
    ザに生成させる第３プログラムを作る前記第１プログラ
    ムを静的に解析するステップと、及び前記第１の情報を
    グラフ表示する前記ステップで使われた流れ図のグラフ
    表示を作るために、グラフブラウザをプログラムするス
    テップとからさらになることを特徴とする請求項１７記
    載の方法。