sjljとdwarfとsehの違いは何ですか？

プロジェクトのコンパイルに使用するコンパイラを決定するのに十分な情報が見つかりません。プロセスをシミュレートするさまざまなコンピューター上にいくつかのプログラムがあります。Linuxでは、GCCを使用しています。すべてが素晴らしいです。私はコードを最適化することができます、それは速くコンパイルし、それほど多くのメモリを使用しません。

私はMSVCおよびGCCコンパイラーで独自のベンチマークを行います。後で、（サブアーキテクチャごとに）わずかに高速なバイナリが生成されます。コンパイル時間はMSVCよりはるかに長いですが。

そこで、MinGWを使用することにしました。ただし、例外処理メソッドとそのMinGWでの実装に関する説明は見つかりません。異なるオペレーティングシステムとアーキテクチャに異なるディストリビューションを使用できます。

考慮事項：

• コンパイル時間とメモリは、私の使用にとって重要ではありません。重要なのはランタイムの最適化だけです。プログラムが十分に高速である必要があります。遅いコンパイラでも問題ありません。
• OS：Microsoft Windows XP / 7/8 / Linux
• アーキテクチャ：Intel Core i7 / Core2 /およびXPを実行している非常に古いi686：P

MinGW-w64 Wikiに短い概要があります。

mingw-w64 gccがDwarf-2例外処理をサポートしないのはなぜですか？

Windows のDwarf-2 EH実装は、64ビットWindowsアプリケーションで動作するように設計されていません。win32モードでは、例外アンワインドハンドラーは非dw2対応のコードを介して伝播できません。つまり、WindowsシステムDLLやVisual Studioで構築されたDLLなど、dw2非対応の「外部フレーム」コードを通過する例外は失敗します。gccのドワーフ2巻き戻しコードはx86巻き戻しアセンブリを検査し、他のドワーフ2巻き戻し情報がないと続行できません。

例外処理のSetJump LongJumpメソッドは、一般的な保護違反を除いて、ほとんどの場合、win32とwin64の両方で機能します。gccの構造化例外処理サポートは、dw2とsjljの弱点を克服するために開発されています。win64では、展開情報がxdata-sectionに配置され、スタックの代わりに.pdata（関数記述子テーブル）があります。win32の場合、ハンドラーのチェーンはスタック上にあり、実際に実行されたコードによって保存/復元する必要があります。

例外処理に関するGCC GNU：

GCCは、例外処理（EH）の2つの方法をサポートしています。

• DWARF-2（DW2）EH、DWARF-2（またはDWARF-3）デバッグ情報の使用が必要です。DW-2 EHを使用すると、実行可能ファイルに大きな呼び出しスタックの巻き戻しテーブルを含める必要があるため、実行可能ファイルがわずかに肥大化する可能性があります。
• setjmp / longjmp（SJLJ）に基づくメソッド。SJLJベースのEHは、DW2 EHよりもはるかに低速です（例外がスローされない場合、通常の実行でもペナルティを課します）。

[...]

構造化例外処理（SEH）

Windowsは、構造化例外処理（SEH）と呼ばれる独自の例外処理メカニズムを使用しています。[...] 残念ながら、GCCはまだSEHをサポートしていません。[...]

以下も参照してください。

• GCCの例外処理モデル
• IA-64のC ++例外処理
• EH初心者向けハウツー

SJLJ（setjmp / longjmp）：– 32ビットおよび64ビットで使用可能–「ゼロコスト」ではない：例外がスローされない場合でも、パフォーマンスに若干のペナルティ（例外の重いコードでは約15％）が発生–例外を許可Windowsコールバックなどをトラバースする

DWARF（DW2、dwarf-2）– 32ビットでのみ使用可能–永続的なランタイムオーバーヘッドなし–コールスタック全体をdwarf対応にする必要があります。つまり、WindowsシステムDLLなどの例外をスローできません。

SEH（ゼロオーバーヘッド例外）– 64ビットGCC 4.8で利用可能になります。

ソース：http : //qt-project.org/wiki/MinGW-64-bit