sjlj vs dwarf vs sehの違いは何ですか？
プロジェクトのコンパイルに使用するコンパイラを決定するための十分な情報が見つかりません。プロセスをシミュレートするさまざまなコンピューター上にいくつかのプログラムがあります。 Linuxでは、GCCを使用しています。すべてが素晴らしいです。コードを最適化することができます。高速にコンパイルされ、あまりメモリを使用しません。
私はMSVCおよびGCCコンパイラで独自のベンチマークを実行します。後で、サブアーキテクチャごとに少し高速なバイナリが生成されます。コンパイル時間はMSVCよりもはるかに長いですが。
そこで、MinGWを使用することにしました。しかし、MinGWでの例外処理メソッドとその実装に関する説明は見つかりません。異なるオペレーティングシステムとアーキテクチャに対して異なるディストリビューションを使用できます。
考慮事項：
- コンパイル時間とメモリは、私の使用にとって重要ではありません。重要なのはランタイムの最適化だけです。プログラムが十分に高速である必要があります。遅いコンパイラは許容されます。
- OS：Microsoft Windows XP/7/8/Linux
- アーキテクチャ：Intel Core i7/Core2 /およびXP：Pを実行している非常に古いi686
MinGW-w64 Wiki に概要があります：
mingw-w64 gccがDwarf-2例外処理をサポートしないのはなぜですか？
Windows用のDwarf-2 EH実装は、64ビットWindowsアプリケーションで動作するようにはまったく設計されていません。 win32モードでは、例外アンワインドハンドラーは非dw2対応のコードを介して伝播できません。これは、WindowsシステムDLLやVisual StudioでビルドされたDLLなど、dw2非対応の「外部フレーム」コードを通過する例外は失敗することを意味します。 gccのDwarf-2アンワインドコードは、x86アンワインドアセンブリを検査し、他のdwarf-2アンワインド情報がなければ続行できません。
例外処理のSetJump LongJumpメソッドは、一般保護違反を除き、win32とwin64の両方でほとんどの場合に機能します。 dw2とsjljの弱点を克服するために、gccの構造化例外処理サポートが開発されています。 win64では、アンワインド情報はxdata-sectionに配置され、スタックの代わりに.pdata（関数記述子テーブル）があります。 win32の場合、ハンドラーのチェーンはスタック上にあり、実際に実行されたコードによって保存/復元する必要があります。
GCC GN 約例外処理：
GCCは、例外処理（EH）の2つの方法をサポートしています。
- DWARF-2（DW2）EH。DWARF-2（またはDWARF-3）デバッグ情報を使用する必要があります。 DW-2 EHでは、実行可能ファイルに大きなコールスタック展開テーブルを含める必要があるため、実行可能ファイルがわずかに肥大化する可能性があります。
- setjmp/longjmp（SJLJ）に基づく方法。 SJLJベースのEHは、DW2 EHよりはるかに低速です（例外がスローされない場合は通常の実行でもペナルティを与えます）が、GCCでコンパイルされていないコードまたはコールスタックのアンワインド情報を持たないコードで動作できます。
[...]
構造化例外処理（SEH）
Windowsは、構造化例外処理（SEH）と呼ばれる独自の例外処理メカニズムを使用します。 [...]残念ながら、GCCはまだSEHをサポートしていません。 [...]
こちらもご覧ください：
SJLJ（setjmp/longjmp）：– 32ビットおよび64ビットで使用可能–「ゼロコスト」ではない：例外がなくてもスローされると、わずかなパフォーマンスのペナルティが発生します（例外の重いコードでは最大15％）-例外が通過することを許可しますWindowsコールバック
DWARF（DW2、dwarf-2）– 32ビットのみで使用可能–永続的なランタイムオーバーヘッドなし–コールスタック全体をdwarf対応にする必要があります。これは、たとえば、例外をスローできないことを意味しますWindowsシステムDLL。
SEH（オーバーヘッド例外ゼロ）– 64ビットGCC 4.8で利用可能になります。