なぜコンパイラはINT3命令をサブルーチン間に挿入するのですか？

Question

いくつかのソフトウェアをデバッグ中に、多くの場合、INT3命令がサブルーチンの間に挿入されていることに気付きました。

Iは、これらの技術的サブルーチンはどちらの理由末尾にretnを実行しない場合は、実行を一時停止するために機能し、その代わりにそれらの後に、「間」に挿入されていないと仮定する。

私の前提は正しいですか？これらの命令の目的は何ですか？

Answer 1

Linuxの場合、gccとclangパッドは0x90（NOP）で機能を整列します。 （リンカでさえ、.oを不均一なサイズのセクションにリンクするとき）。

通常、CPUが関数の最後にRET命令の分岐予測を持たない場合を除いて、特別な利点はありません。その場合、NOPは、正しい分岐ターゲットが発見されてから回復するまでに時間がかかるものでCPUを起動させません。

---

関数の最後の命令がRETでない可能性があります。それは間接的なJMP（例えば、関数ポインタによるテールコール）であってもよい。その場合、分岐予測が失敗する可能性が高くなります。 （CALL/RETペアはリターンスタックによって特別に予測されますが、RETは間接JMPであり、基本的にはjmp [rsp]とadd rsp, 8です）。

間接JMPまたはCALL（ブランチターゲットバッファ予測が使用できない場合）のデフォルト予測では、次の命令にジャンプします。 （正しいターゲットがわかるまでは予測もストールもないか、オプションではないか、またはデフォルトの予測がジャンプテーブルに十分使える） FP sqrtやマイクロコード化されたもののように簡単に中断すると、分岐予測ミスが増します。投機的に実行された命令がTLBミスを引き起こし、ハードウェアのページウォークをトリガしたり、そうでなければキャッシュを汚染したりする場合はさらに悪化する。

例外を生成する命令INT 3には、これらの問題がありません。 CPUはINTを実行する前に実行しようとはしません。何も悪いことはありません。 IIRCでは、次の命令のデフォルト予測が有用でない場合、間接JMPの後にそのようなものを配置することをお勧めします。機能間のランダムなゴミで

---

、RETを含むマシンコードの偶数プリデコード16Bブロックが遅く可能性があります。現代のCPUは、4つの命令のグループで並列にデコードするため、命令がすでにデコードされてから、RETを検出することはできません。 （これは投機的実行とは異なります）。無条件ブランチ（RETのような）の後のバイトの長さの変更が遅延するのを避けることは、ブランチのデコードを遅らせるので便利です。

LCPストールはインテルCPUにのみ影響します。AMDはL1キャッシュの命令境界をマークし、大きなグループでデコードします。 （インテルはデコードされたuopキャッシュを使用してループ内で毎回実際にデコードするための電力コストなしで高いスループットを得る）。インテルCPUでは命令長の発見が実際のデコードよりも早い段階で行われることに注意してください。例えば、Sandybridgeフロントエンドは、次のようになります。

（デイビット・カンターのハスウェルの過去記事からコピーされたダイアグラムでも、私は彼のSandybridgeの過去記事にリンクされている彼らは両方の優れている。。）

この回答（とはるかに）で説明した内容については、Agner Fog's microarch pdfとx86タグwikiのその他のリンクも参照してください。

Answer 2

誤った前提。

これらは関数間でパディングされています。命令をスキップすることをランダムに決定したCPUは壊れてしまい、投げ捨てるべきです。

INT 3の理由は2倍です。これは1バイトの命令です。つまり、1バイトのスペースがあっても使用できます。命令の大部分は、長すぎるため不適切です。さらに、それは "デバッグブレーク"命令です。これは、デバッガが関数間でコードを実行しようとする試みをキャッチできることを意味します。これは、retnを無視することによって引き起こされるのではなく、初期化されていない関数ポインタを使用するなどの単純な理由によるものです。