在Windows上，有两种类型的异常处理：结构化异常处理(SEH)和向量异常处理(VEH)。
MSVC生成的二进制文件使用SEH,其中单个函数都有附加的异常处理程序。在64位系统上，这些存储在PE的.pdata部分的表中。当一个函数抛出异常(例如，由于非法指令或除以零),如果有的话，它的SEH将被调用。
Go运行时使用VEH,其中整个运行时具有一系列处理器，VEH通过它们跳转，直到达到终止点。
当抛出异常时，ntdll在执行VEH之前先执行SEH。这是合理的行为，但对我们使用VEH的方式构成了一个问题。
最近的MSVC工具链生成arm64 DLL,通过测试一些指令来探测ARMv8.1原子性，并使用SEH捕获潜在的非法指令异常，指示这些指令不存在。由最近的MSVC工具链生成的ARM64 DLL在初始化期间无条件地执行此操作。
当Go运行时加载其中一个这样的DLL(像正常一样使用LoadLibrary)时，其VEH处理程序将为探测到的非法指令异常生成的异常调用。然后Go VEH处理程序决定它是致命的，退出。这是一个大问题。
我看到了几种解决这个问题的方法：

1. 我们对从Go的.text部分之外抛出的非法指令异常进行特殊处理(如我在https://go-review.googlesource.com/c/go/+/340070中所做的那样)。这工作得很好(我现在正在发货),似乎是最不侵入性的更改。然而，这可能会掩盖从Go的.text部分之外抛出的未被捕获和处理的其他非法指令异常，在这种情况下，二进制文件将在没有输出堆栈跟踪的情况下终止。这似乎是一个不太可能且无关紧要的边缘情况。
2. 我们总是允许我们的VEH在来自Go的.text部分之外的异常情况下继续执行到SEH(或什么都不做)。这会起作用，但也意味着由库函数引起的合法崩溃不会导致打印Go堆栈跟踪。我有点喜欢这个解决方案，但我可以想象其他人可能不喜欢。而且那些堆栈跟踪可能非常有用。这意味着删除我们在runtime/中拥有的TestRaiseException单元测试。
3. 如果异常来自Go的.text部分之外并且存在该函数的SEH,我们允许VEH继续执行到SEH。这是(1)的一个更一般的情况，也许是一个非常好的解决方案。我可以完成必要的逆向工程来实现这一点，尽管这并不容易。然而，如果SEH决定不继续执行而是崩溃，我们就不会打印堆栈跟踪。那边缘情况会在什么地方被触发还有待观察。
4. 当我们允许VEH继续执行到SEH时，如果SEH存在并且被调用了，我们就直接让我们的VEH调用一个SEH,只有在SEH被调用后才用堆栈跟踪崩溃。这非常棘手，但可能会给我们带来最好的结果。
5. 我们做(2),但然后安装一个SEH(使用RtlAddFunctionTable)用于syscall.Syscall的IP打印堆栈跟踪，这样我们最终确实会得到由于(2)传递给VEH的未处理异常。这似乎简单一些，尽管我怀疑我们可能会错过由非Go代码创建的线程引起的堆栈跟踪。
   在我进一步考虑这个问题之前，我想我们应该先讨论一下所有这些。无论如何，https://go-review.googlesource.com/c/go/+/340070目前作为一个临时解决方案可以工作。
   CC @rsc@ianlancetaylor@aclements@cherrymui@bradfitz@alexbrainman@jstarks