Sjlj 和侏儒和 seh 有什么区别?

我找不到足够的信息来决定应该使用哪个编译器来编译我的项目。在不同的计算机上有几个程序模拟一个过程。在 Linux 上,我使用的是 GCC。一切都很好。我可以优化代码,编译速度很快,而且不需要太多内存。

我用 MSVC 和 GCC 编译器做了自己的基准测试。稍后,生成速度稍快的二进制文件(对于每个子体系结构)。虽然编译时间远远超过 MSVC。

所以我决定用 MinGW。但是在 MinGW 中找不到任何关于异常处理方法及其实现的解释。我可以为不同的操作系统和架构使用不同的发行版。

考虑因素:

  • 编译时间和内存对我的使用并不重要。唯一重要的是运行时优化。我需要我的程序足够快。慢速编译器是可以接受的。
  • 操作系统: Windows XP/7/8/Linux
  • 架构: Intel Core i7/Core2/和一个运行 XP: P 的非常老的 i686
124683 次浏览

SJLJ (setjmp/longjmp) :-可用于32位和64位-而不是“零成本”: 即使没有抛出异常,也会引发次要异常 性能损失(异常大的代码约为15%)-允许异常 遍历例如 windows 回调

DWARF (DW2,侏儒-2)-仅适用于32位-没有永久的运行时开销-需要整个调用堆栈支持侏儒 意味着不能抛出异常,例如 Windows 系统 DLL。

SEH (零开销异常)-将可用于64位 GCC 4.8。

来源: https://wiki.qt.io/MinGW-64-bit

MinGW-w64 Wiki有一个简短的概述:

为什么 mingw-w64 gcc 不支持 Dwarf-2异常处理?

Windows 的 矮人 -2 EH实现的设计目的根本不是为了 在64位 Windows 应用程序下工作。在 win32模式下,异常 Unwind 处理程序不能通过非 dw2感知代码进行传播,这意味着 任何异常通过任何非 dw2感知的“外部帧” 代码将失败,包括 Windows 系统 DLL 和使用 VisualStudio.Dwarf-2在 gcc 中展开代码检查 x86 不能在没有其他矮星 -2的情况下继续进行 放松信息。

异常处理的 跳远方法适用于大多数情况 除了一般的保护故障外,win32和 win64都有。 正在开发 gcc 中的结构化异常处理支持 克服 dw2和 sjlj 的弱点 Unwind-information 放在 xdata-section 中,其中有. pdata (函数描述符表)代替堆栈 的处理程序在堆栈上,需要由 real 保存/恢复 执行代码。

GCC GNU 关于 异常处理:

GCC 支持两种异常处理(EH)方法:

  • DWARF-2(DW2) EH ,这需要使用 DWARF-2(或 DWARF-3)调试信息 稍微膨胀,因为大的调用堆栈退出表必须 包含在可执行文件中。
  • 一种基于 Setjmp/longjmp (SJLJ).SJLJ 的 EH 方法比 DW2EH 慢得多(即使是正常执行时,如果没有 异常) ,但可以跨尚未引发异常的代码工作 使用 GCC 编译或者没有调用堆栈展开的 资料。

[ ... ]

结构化异常处理(SEH)

Windows 使用自己的异常处理机制,称为结构化异常处理(SEH)。 < em > [ ... ] 不幸的是,GCC 还不支持 SEH

参见: