c++ - SEH(结构化异常处理)机制在ARM上究竟是如何工作的？

Question

我知道总体概述:http://msdn.microsoft.com/en-us/library/dn743843.aspx ;关于 win32 和 win64 的异常机制有很多可用的信息，但 ARM 不是很清楚。

我想知道:当产生机器异常(违反内存保护)时，究竟控制转移到了哪里(这样我就可以设置断点)？它是否转移到内核模式？据推测，它从 vector 表中查找处理程序的地址并传输到那里。 内核 代码执行 SEH 展开，还是在用户模式下完成展开？如果在用户模式下，究竟在哪里 - .exe、coredll 或其他地方的一部分？

背景

我们有一个大型应用程序，它在每个线程的顶层放置 __try/__except 处理程序，以便以信息丰富的方式记录崩溃。这在 MIPS 上运行良好多年。我们现在将它移植到 ARM 上的 WinCE 7，在 VS2008 下构建。我们发现在发布版本中有时无法正确处理异常。这似乎完全取决于代码中生成异常的位置(我有一个测试函数，它故意访问 NULL 指针以引发 SEH 异常，我从代码中的不同位置调用它)。

我们正在使用/EHsc 选项来启用 SEH。发布版本使用/O2/Os ；删除/O2 使其工作但速度明显变慢。这使我相信优化器正在删除 SEH 工作所需的内容——但究竟是什么？并非所有函数都有“mov r12, sp ...”序言，但有些函数仍然不能正常工作。 PDATA 中是否有错误？ PDATA 条目的数量是否有上限？ “dumpbin/pdata”的输出不是每一行都有一个函数名是正常的吗？

通过使用调试器(尽管是发布版本)，我可以在我的异常过滤函数(从 __except 调用)的开头放置一个断点，并观察到它永远不会进入失败案例。程序刚刚退出。

Answer 1

我不熟悉低级内核细节，但指向 CRT 异常处理程序的指针存储在函数之前的双字中:

0001106C     DCD _C_specific_handler  ; handler function
00011070     DCD _scope_table         ; scope table (__try/__except map)
00011074 start
00011074     MOV             R12, SP

也许将您的断点放在 _C_specific_handler 上并查看它是否被调用。实际功能在 COREDLL 中。如果它确实被调用但没有将异常传递给您的代码，则范围表信息可能由于某种原因是错误的。

编辑:以上适用于 WinCE 6 及更早版本。既然你提到了 VS2008，我很确定 WinCE 7 仍然使用相同的异常处理模型。您提到的链接(基于展开代码)适用于新的、仅限 ARMv7 的 WinRT 内核(我认为 Windows Embedded Compact 2013 也使用它)。