sjlj vs dwarf vs seh有什么区别？ [英] What is difference between sjlj vs dwarf vs seh?
问题描述
我用MSVC和GCC编译器做我自己的基准。后来一个产生略快的二进制（对于每个子体系结构）。虽然编译时间远远超过MSVC。
所以我决定使用MinGW。但是在MinGW中找不到任何关于异常处理方法及其实现的解释。我可以为不同的操作系统和体系结构使用不同的发行版。
注意事项：
- 编译时间和记忆对我的使用不重要。只有重要的是运行时优化。我需要我的程序足够快。慢编译器是可以接受的。
- 操作系统：Microsoft Windows XP / 7/8 / Linux
- 架构：Intel Corei7 / Core2和运行XP的旧版i686： / li>
不mingw-w64 gcc支持Dwarf-2异常处理？
Windows的 Dwarf-2 EH 设计为
在64位Windows应用程序下工作。在win32模式下，异常
unwind处理程序不能传播通过非dw2感知代码，这意味着
任何异常通过任何非dw2感知外框架
代码将失败，包括Windows系统DLL和使用
Visual Studio构建的DLL。在gcc中的Dwarf-2展开代码检查x86
展开程序集，并且在没有其他dwarf-2
展开信息的情况下无法继续。
strong> SetJump LongJump 异常处理方法适用于win32和win64上的大多数
情况，除了常规保护错误。
gcc中的结构化异常处理支持正在开发到
，克服了dw2和sjlj的弱点。在win64上，
unwind-information放置在xdata-section中，并且有.pdata
（函数描述符表）而不是堆栈。对于win32，处理程序链
在堆栈上，需要通过真实的
执行代码保存/恢复。
GCC GNU 有关异常处理：
GCC支持两种异常处理方法（EH）：
- DWARF- 2（DW2）EH ，这需要使用DWARF-2（或DWARF-3）调试信息。 DW-2 EH可以导致可执行文件
略显膨胀，因为大的调用堆栈解开表必须包含在可执行文件中的
。
- 基于 > setjmp / longjmp（SJLJ）。基于SJLJ的EH比DW2 EH慢得多（在没有
异常时会惩罚甚至正常执行），但是可以在没有使用GCC编译的代码或没有调用堆栈的代码上工作
结构化异常处理（SEH）
Windows使用自己的异常处理机制。 [...]
不幸的是，GCC不支持SEH。 [...]
另请参阅：
Well, that's all. I can't find enough information to decide which compiler should I use to compile my project. There are several programs on different computers simulating a process. On Linux I'm using GCC. Everything is great. I can optimize code, it compiles fast and uses not-so-much memory.
I do my own benchmark with MSVC and GCC compilers. Later one produces slightly faster binaries (for each subarchitecture). Though compile time is much more than MSVC.
So I decided to use MinGW. But can't find any explanation about exception handling methods and their implementations in MinGW. I can use different distributions for different operating systems and architectures.
Considerations:
- Compile time and memory are not important for my usage. Only important thing is runtime optimization. I need my programs to be fast enough. Slow compiler is acceptable.
- OS: Microsoft Windows XP / 7 / 8 / Linux
- Architecture: Intel Corei7 / Core2 / and a very old i686 running XP :P
There's a short overview at MinGW-w64 Wiki:
Why doesn't mingw-w64 gcc support Dwarf-2 Exception Handling?
The Dwarf-2 EH implementation for Windows is not designed at all to work under 64-bit Windows applications. In win32 mode, the exception unwind handler cannot propagate through non-dw2 aware code, this means that any exception going through any non-dw2 aware "foreign frames" code will fail, including Windows system DLLs and DLLs built with Visual Studio. Dwarf-2 unwinding code in gcc inspects the x86 unwinding assembly and is unable to proceed without other dwarf-2 unwind information.
The SetJump LongJump method of exception handling works for most cases on both win32 and win64, except for general protection faults. Structured exception handling support in gcc is being developed to overcome the weaknesses of dw2 and sjlj. On win64, the unwind-information are placed in xdata-section and there is the .pdata (function descriptor table) instead of the stack. For win32, the chain of handlers are on stack and need to be saved/restored by real executed code.
GCC GNU about Exception Handling:
GCC supports two methods for exception handling (EH):
- DWARF-2 (DW2) EH, which requires the use of DWARF-2 (or DWARF-3) debugging information. DW-2 EH can cause executables to be slightly bloated because large call stack unwinding tables have to be included in th executables.
- A method based on setjmp/longjmp (SJLJ). SJLJ-based EH is much slower than DW2 EH (penalising even normal execution when no exceptions are thrown), but can work across code that has not been compiled with GCC or that does not have call-stack unwinding information.
[...]
Structured Exception Handling (SEH)
Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). [...] Unfortunately, GCC does not support SEH yet. [...]
See also:
这篇关于sjlj vs dwarf vs seh有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
