问题描述
我找不到足够的信息来决定我应该使用哪个编译器来编译我的项目.在不同的计算机上有几个程序模拟一个过程.在 Linux 上，我使用的是 GCC.一切都很好.我可以优化代码，它编译速度快并且使用的内存不多.
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.
我用 MSVC 和 GCC 编译器做我自己的基准测试.后来的一个产生稍微快一点的二进制文件(对于每个子架构).虽然编译时间远远超过 MSVC.
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.
所以我决定使用 MinGW.但是在MinGW中找不到关于异常处理方法及其实现的任何解释.我可以为不同的操作系统和架构使用不同的发行版.
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.
注意事项:
- 编译时间和内存对我的使用并不重要.唯一重要的是运行时优化.我需要我的程序足够快.慢速编译器是可以接受的.
- 操作系统:Microsoft Windows XP/7/8/Linux
- 架构:Intel Core i7/Core2/和运行 XP 的非常老的 i686 :P
推荐答案
在 MinGW-w64 维基:
为什么 mingw-w64 gcc 不支持 Dwarf-2 异常处理?
Windows 的 Dwarf-2 EH 实现根本不是为了在 64 位 Windows 应用程序下工作.在win32模式下，异常展开处理程序不能通过非 dw2 感知代码传播，这意味着任何通过任何非 dw2 感知的外部框架"的异常代码将失败，包括 Windows 系统 DLL 和使用构建的 DLL视觉工作室.gcc 中的 Dwarf-2 展开代码检查 x86展开组装，没有其他 dwarf-2 就无法进行放松信息.
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.
SetJump LongJump 异常处理方法适用于大多数情况win32 和 win64 上的情况，一般保护故障除外.gcc 中的结构化异常处理支持正在开发中克服了dw2和sjlj的弱点.在 win64 上，展开信息被放置在 xdata-section 并且有 .pdata(函数描述符表)而不是堆栈.对于win32，链的处理程序在堆栈上，需要由 real 保存/恢复执行代码.
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 关于异常处理:
GCC 支持两种异常处理方法 (EH):
- DWARF-2 (DW2) EH，需要使用 DWARF-2(或 DWARF-3)调试信息.DW-2 EH 可能导致可执行文件略微臃肿，因为必须是大型调用堆栈展开表包含在可执行文件中.
- 一种基于setjmp/longjmp (SJLJ)的方法.基于 SJLJ 的 EH 比 DW2 EH 慢得多(即使没有正常执行也会受到惩罚)异常被抛出)，但可以跨尚未被抛出的代码工作使用 GCC 编译或没有调用堆栈展开信息.
- 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.
[...]
结构化异常处理 (SEH)
Windows 使用自己的异常处理机制，称为结构化异常处理 (SEH).[...]不幸的是，GCC 还不支持 SEH.[...]
Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). [...] Unfortunately, GCC does not support SEH yet. [...]
另见:
这篇关于sjlj vs dwarf vs seh 有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！