これは、多くの設計上の決定と機能のトレードオフを含む、驚くほど重要な作業量です。考慮してください：あなたはデバッグしています。デバッグ対象は中断されます。メモリ内のイメージには、ソースのオブジェクト コードと、オブジェクトのバイナリ レイアウト、ヒープ、スタックが含まれています。デバッガーはメモリ イメージを検査しています。シンボル、タイプ、アドレス マッピング、PC (IP) からソースへの対応に関するデバッグ情報がロードされています。コール スタック、データ値が表示されます。
ここで、デバッグ対象を停止して再起動することなく、コードやデータに対する特定の一連の編集を許可したいと考えています。最も簡単なのは、コードの 1 行を別の行に変更することです。おそらく、そのファイルまたはその関数だけ、またはその行だけを再コンパイルします。今度は、デバッグ対象イメージにパッチを適用して、次にステップ オーバーするか別の方法で実行するときにその新しいコード行を実行する必要があります。ボンネットの下でどのように機能しますか？コードが置き換えられたコード行よりも大きい場合はどうなりますか? コンパイラの最適化とどのように相互作用しますか? おそらく、EnC デバッグ ターゲット用に特別にコンパイルされた場合にのみ、これを行うことができます。おそらく、EnC に合法である可能性のあるサイトを制限するでしょう。考えてみてください: コール スタックで中断された関数のコード行を編集するとどうなるでしょうか。コードがそこに戻ったとき、関数の元のバージョンまたは行が変更されたバージョンを実行しますか? 元のバージョンの場合、そのソースはどこから来たのですか?
ローカルを追加または削除できますか? 中断されたフレームのコール スタックはどうなりますか? 現在の機能の？
関数シグネチャを変更できますか? オブジェクトにフィールドを追加/オブジェクトからフィールドを削除しますか? 既存のインスタンスはどうですか? 保留中のデストラクタまたはファイナライザはどうですか? 等。
あらゆる種類の使用可能な EnC を動作させるには、非常に多くの機能の詳細に注意する必要があります。次に、EnC に電力を供給するためのインフラストラクチャを提供するために必要な、ツール間の統合に関する多くの問題があります。特に、編集前および編集後のデバッグ情報とオブジェクト コードをデバッガで利用できるようにする、ある種のデバッグ情報のリポジトリがあると役立ちます。C++ の場合、PDB の増分更新可能なデバッグ情報が役立ちます。インクリメンタル リンクも役立つ場合があります。
MS エコシステムから GCC エコシステムに目を向けると、GDB/GCC/binutils 全体の複雑さと統合の問題、無数のターゲット、必要な EnC 固有のターゲット抽象化、および「あると便利だが重要ではない」性質が容易に想像できます。の EnC が、GDB/GCC にまだ登場していない理由です。
ハッピーハッキング！
(ps Smalltalk-80 の対話型プログラミング環境で何ができるかを見ることは、有益で刺激的です。St80 では、「再起動」の概念はありませんでした。そのような環境では、オブジェクトのバージョン管理は仮定ではありませんでした。)