プログラム アニメーションまたはステップ実行とは、一度に 1 つの命令または行ずつコードを実行するデバッグ方法を指します。プログラマーは、特定のコード行の実行前と実行後のプログラム、マシン、および関連データの状態を調べることができます。これにより、プログラマーは各ステートメントまたは命令の効果を個別に評価し、実行中のプログラムの動作 (または不正動作) を詳しく把握できます。最近のほぼすべてのIDEとデバッガーは、この実行モードをサポートしています。
歴史

命令ステップまたはシングル サイクルは、もともとプロセッサクロックを停止し、手動で 1 サイクルずつ進める 手法を指していました。これを可能にするには、次の 3 つのことが必要です。
- 時計を停止できるコントロール (例: 「停止」ボタン)。
- 停止したクロックを手動で 1 サイクル進めるための 2 番目のコントロール (例: 「命令ステップ」スイッチと「開始」ボタン)。
- 各サイクル後のプロセッサの状態を記録する手段 (例: レジスタやメモリの表示)。
1964 年に発表されたIBM System 360プロセッサ シリーズでは、これらの機能はフロント パネルのスイッチ、ボタン、およびネオン ライトの列によって提供されました。PDP -11などの他のシステムでも同様の機能が提供されていました。
新しいプロセッサでは、クロックの物理的な停止をサポートしておらず、内部状態が多すぎてパネルに適切に表示できない場合があります。トラップ フラグ を介して同様の機能が提供される場合があります。トラップ フラグを有効にすると、ブレークポイントと同様の方法で、各命令の後にプロセッサを停止するように指示します。
マルチプロセスが一般的になるにつれ、多くの独立したプロセスが同時に停止するため、このような手法の実用性は限られるようになりました。このため、同様の機能を提供しながらも、ブレークポイントと命令のステップ実行を特定のアドレス空間とスレッド内の特定のアプリケーション プログラムに意図的に制限する、複数の独立ベンダーによる独自ソフトウェアの開発が行われました。プログラムの状態 (選択したアプリケーション/スレッドに該当するもの) は、各ステップで検査するために保存され、再開前に復元されたため、単一のユーザー環境であるかのような印象を与えました。通常、これはアプリケーション レイヤーの問題を診断するのに十分です。
物理的な停止ボタンを使用して実行を一時停止し、その後アプリケーション プログラムのステップ実行を開始する代わりに、通常はプログラム内の特定のステートメント/命令 (事前に選択するか、またはデフォルトで最初の命令) でブレークポイントまたは「一時停止」要求を事前に設定する必要があります。
プログラムのフルスクリーン「アニメーション」を実現するには、通常、ビデオ モニターなどの適切な I/O デバイスが必要です。このデバイスは、コードの適切なセクション (たとえば、逆アセンブルされたマシン コードまたはソース コード形式) を表示でき、現在の命令またはソース コードの行へのポインター (たとえば、<==) を提供できます。このため、メインフレームの世界でこれらのフルスクリーン アニメーターが広く使用されるようになるには、1970 年代初頭のCICSなどのトランザクション処理システムの登場を待たなければなりませんでした。当初は、その環境内で動作するアプリケーション プログラムのデバッグに限定されていました。同じ製品の後のバージョンでは、バッチ プログラムや他のオペレーティング システムやプラットフォームのクロス リージョンの監視/デバッグが可能になりました。
1980 年頃からパーソナル コンピュータが導入されるようになり、統合デバッガーをこの単一のユーザー ドメインにさらに広く組み込むことができるようになり、ユーザー画面を分割してデバッグ「コンソール」を追加し、プログラマーとの対話を可能にすることで、同様のアニメーションが提供されるようになりました。
Borland Turbo Debugger は、1989 年に導入されたスタンドアロン製品で、PC 用のフルスクリーン プログラム アニメーションを提供しました。後のバージョンでは、コンパイル時に抽出された実際のソース ラインとアニメーションを組み合わせるサポートが追加されました。
プログラムアニメーションのテクニック
プログラムの実行中に「アニメーション」を作成するためのソフトウェア手法は少なくとも 3 つあります。
- インストルメンテーションでは、コンパイル時にプログラムに追加のソース コードを追加し、各ステートメントの前または後にアニメーターを呼び出して通常の実行を停止します。この機能は、Python の pdb モジュールのようにランタイム ライブラリの一部である場合もあれば、外部デバッガーが接続されている場合にそれをトリガーするブレークポイント命令を挿入する形式をとる場合もあります。
- 誘発割り込みこの手法では、実行時にプログラム内の特定のポイントにブレークポイントを強制的に設定し、通常はそのポイントのマシン コード命令を変更して (挿入されたシステム コールまたは意図的な無効な操作の場合があります)、割り込みを待機します。割り込みが発生すると、テスト ツールによって処理され、ステータスがプログラマーに報告されます。この方法では、割り込みが発生するまでプログラムをフル スピードで実行できますが、割り込みに至るまでのほとんどの命令がツールによって監視されないという欠点があります。
- 命令セット シミュレーターこの手法では、コンパイルされたプログラムのマシン コードを入力「データ」として扱い、ホスト マシン命令を完全にシミュレートし、条件付きまたは無条件のブレークポイント、または各ステップ間のプログラマーが要求した「単一サイクル」アニメーション要求のコードを監視します。
方法の比較
最後の方法の利点は、コンパイルされたプログラムに変更を加えずに診断を行えることと、ツールが追加のソフトウェア トレース機能を使用してホスト システムの診断を拡張できるため、広範な診断の範囲がほぼ無制限であることです。 また、この手法を使用して、ストレージ違反やバッファー オーバーフローなどの多くのプログラム エラーを自動的に診断 (および防止)することもできます。 自動命令トレースと命令カウントしきい値 (例: 10,000 命令後に一時停止し、最後の n 命令を表示する) を組み合わせて使用することで、ループ検出も可能です。 2 番目の方法では、実行前に停止する命令のみを変更し、プログラマーがオプションで再開する前にその命令を復元することもできます。 一部のアニメーターでは、要件に応じて複数の方法をオプションで使用できます。 たとえば、方法 2 を使用して特定のポイントまでフル スピードで実行し、その後、命令セット シミュレーションを使用します。
追加機能
アニメーターは、プログラム トレース、ダンプ、条件付きブレークポイントとメモリ変更、プログラム フロー変更、コード カバレッジ分析、「ホット スポット」検出、ループ検出などの他のテスト/デバッグ機能を組み合わせることも、組み合わせないこともできます。
参考文献
外部リンク
- ステップ実行 (Visual Studio) Microsoft Corporation の IDEであるVisual Studioにおけるステップ実行サポートの概要
- Tarrainim - プログラム アニメーション環境
- プログラム設計と分析を教え、学ぶためのプログラムアニメーション
- ソフトウェアテストに関する構造化された情報(ソフトウェアテストの歴史など)は、テスト参考文献によって公開されています。
