ブレークポイント

ソフトウェア開発において、ブレークポイントとは、デバッグの目的でプログラム内に意図的に停止または一時停止する場所を指します。単に一時停止と呼ばれることもあります。

より一般的には、ブレークポイントは、プログラムの実行中にプログラムに関する情報を取得する手段です。中断中に、プログラマーはテスト環境(汎用レジスタ、メモリ、ログ、ファイルなど) を検査して、プログラムが期待どおりに機能しているかどうかを確認します。実際には、ブレークポイントは、プログラムの実行をいつ中断するかを決定する 1 つ以上の条件で構成されます。

ブレークポイントは、最も初期のデジタルコンピュータの1つであるENIACで、プログラマーのベティ・ホルバートンによって発明されました。^{[1] ENIACの初期の設計では、プログラムの流れは、ユニット間でケーブルを接続することで設定されていました。特定のポイントでプログラムを停止するには、}ブレークポイント と呼ばれるケーブルを取り外しました。^[2]

IBM/360などの初期のメインフレーム コンピュータには、特定の命令記憶アドレスにブレークポイントを設定できるコンソール スイッチ/ダイヤルがあり、「シングル サイクル」操作が提供され、レジスタとメモリの内容をコンソールのライト上で直接確認できました。マルチタスクの出現により、マシン全体が停止するため、このオプションの使用は制限されました。

プログラマーはコンピューターの初期の頃から、マシン コード パッチを使用して単一の破壊的なブレークポイントを実装し、コア ダンプを発生させてきました。コア ダンプは、意図的な「クラッシュ」が発生した瞬間のレジスタとメモリの状態を提供します。

1960 年代にテレタイプライターコンソールが登場したことで、よりインタラクティブなコマンド ラインデバッグ機能が可能になりましたが、マルチタスク環境での完全にインタラクティブなフル スクリーン デバッグが現実のものとなったのは、1970 年代初頭にメインフレームに接続されたビデオ モニターが普及してからです。これにより、レジスタとメモリの変更を同時に表示しながら、真のプログラム アニメーション方式でステップ バイ ステップのプログラム実行も可能になりました。当初、このタイプのアニメーションは、逆アセンブルまたは逆コンパイルされたマシン コードのレベルでしたが、後にHLLソース レベルのアニメーションに進化しました。

ブレークポイントは、プログラマが指定した命令の実行直前に実行中のプログラムを中断するために最もよく使用されます。これは、命令ブレークポイントと呼ばれることがよくあります。

メモリ領域内の特定の場所の読み取り、書き込み、または変更など、他の種類の条件も使用できます。これは、データブレークポイントまたはウォッチポイントと呼ばれることがよくあります。多くのシステムでは、条件が満たされた場合にのみアクティブになるブレークポイントもサポートされており、通常は条件付きブレークポイントと呼ばれます。^[3]

ブレークポイントに到達すると、さまざまなツールを使用してプログラムの状態を検査したり変更したりします。各スレッドのスタック トレースを使用して、一時停止された命令につながった関数呼び出しのチェーンを確認できます。ウォッチリストを使用すると、選択した変数と式の値を表示できます。レジスタの内容、ロードされたプログラムモジュール、およびその他の情報 を表示するツールもあります。

ログポイントは、実行を中断するのではなく、情報のみを印刷（または「ログ」 ）するタイプのブレークポイントです。通常、開発者は、実行が特定のポイントに達したときに印刷するメッセージや変数の値を指定できます。 ^{[4]ログポイントは、デバッグ対象のプログラムにログステートメントを配置する（} printfデバッグ と呼ばれることもあります）代わりに使用され、プログラムを変更することが現実的でない場合に特に役立ちます（たとえば、プログラムによって呼び出される外部ライブラリをデバッグする場合）。

多くのプロセッサには、ブレークポイント (通常は命令ブレークポイントとデータ ブレークポイント) のハードウェアサポートが含まれています。たとえば、x86 命令セット アーキテクチャは、x86 デバッグ レジスタを使用してブレークポイントのハードウェア サポートを提供します。このようなハードウェアには、分岐遅延スロットにある命令にブレークポイントを許可しないなどの制限が含まれる場合があります。この種の制限はプロセッサのマイクロアーキテクチャによって課され、プロセッサごとに異なります。

ハードウェア サポートがない場合 (およびマルチタスク環境の場合)、デバッガーはソフトウェアでブレークポイントを実装する必要があります。命令ブレークポイントの場合、これはブレークポイントの位置にある命令を次のいずれかに置き換えるという比較的単純なタスクです。

• デバッガを直接呼び出す命令（例：システムコール、x86の場合はint3）または
• 意図的なプログラム割り込みを引き起こす無効な命令（その後デバッガによって傍受/処理される）

この手法は、共有プログラム ストレージを使用するマルチタスク システムでは実装が難しくなる可能性があります (割り込みが別のスレッドで発生する可能性があり、そのスレッドの元の命令を復活させる必要があります)。また、プログラムが保護されたメモリ内に存在する場合、命令の上書きが防止される可能性があります。

あるいは、

• 命令セット シミュレーターは、適切な条件テストを独自の通常のプログラム サイクル内に埋め込むだけで、無条件または条件付きのブレークポイントを実装できます。これにより、非侵入的なブレークポイントも自然に可能になります (たとえば、読み取り専用プログラムの場合)。
• インタプリタ型言語では、プログラム サイクルで上記と同じ概念を効果的に使用できます。
• 内部または外部のデバッグ サブルーチンを呼び出す関数を発行する追加のソース ステートメントを使用して、すべてのソース コードを「インストルメント化」することも、もう 1 つの一般的な方法です。この方法ではバイナリサイズが大きくなり、通常のメモリ割り当てと例外ハンドラーに悪影響を与える可能性があります。一部のコンパイラには、この手法を半透過的に実装するための「デバッグ」オプションがあります。

一部のデバッガーでは、再開前にメモリ内のレジスタまたはプログラム変数を変更できるため、テスト目的で「手動でコーディングされた」一時的な割り当てを効果的に導入できます。同様に、プログラム命令をスキップしてプログラム ロジックの変更の影響を判断できる場合が多く、プログラム実行に関する質問に直接的な方法で (つまり、仮定や推測なしで) 回答できます。多くの場合、これは、めったに実行されない、またはまったく実行されない、わかりにくい「イベント駆動型」エラー サブルーチンをテストする唯一の実用的な方法である可能性があります。一時的なソース変更が残るリスクはありません。一時停止したプログラム内で再開場所を手動で変更すると、めったに実行されないコード セクション (特定のハードウェア条件ハンドラーなど) に入ることができます。

ただし、ソフトウェアでデータブレークポイントを実装すると、同じプロセッサ上で追加のリソースが使用されるため、デバッグ対象のアプリケーションのパフォーマンスが大幅に低下する可能性があります。^[5]ただし、これは通常、テスト中に許容され、デバッガから入手できる情報の量は、ハードウェアが認識しているデバッグデータの制限によって制限されることはありません。たとえば、ソフトウェア実装では、プログラム/サブルーチン/命令レベルで論理パスデータを収集して、特定のハードウェアプラットフォームが検査用に保存できるものを大幅に増やすことができます。命令セットシミュレーション方法は、（繰り返し）命令置換方法と比較してオーバーヘッドを大幅に削減し、キャッシュミスも削減します。

一部のプログラミング言語の実装では、デバッグ機能を他のプログラムで使用できるように公開しています。たとえば、一部のFORTRAN方言にはAT、もともと命令ブレークポイントとして機能することを意図した文があります。Python は、 Pythonプログラムからアクセス可能なデバッガを実装しています。^{[6]これらの機能は、} COMEFROM文のように動作するように悪用される 可能性があり、^{[7] 実際に}悪用されています。

• 由来
• プログラムアニメーション（ステップ）
• シモン