OpenBSD内核开发：平台差异下的挑战
在开发运行于Unix环境的软件时，多数情况下能使用相同系统特性并受益于出色开发工具，因为多数处理器提供丰富指令集和虚拟内存等功能。然而，从事内核开发工作时，不同平台的繁杂细节就无法忽视，特定处理器架构的缺陷会带来困扰。例如，操作系统异常处理程序在异常处理返回前执行待处理加载和存储操作的问题，多年来一直困扰开发者。
VAX架构简介
VAX架构于1977年末推出，是最古老的32位架构之一。它拥有庞大指令集和丰富寻址模式，但没有无序执行、分支延迟槽、寄存器重命名、超线程等花哨特性，早期设计甚至没有缓存。当时处理器运行速度不超过内存刷新周期，内存刷新周期随技术进步逐渐缩短。
VAX的异常模型简单，《VAX架构参考手册》中“异常与中断”章节对异常进行了定义：陷阱是在引发异常的指令执行结束时发生的异常，保存在栈上的程序计数器（PC）是下一条正常应执行指令的地址；故障是在指令执行期间发生的异常，会使寄存器和内存保持一致状态，排除故障条件并重新执行指令能得到正确结果，指令发生故障后，保存在栈上的PC指向发生故障的指令。
若处理器遇到无法恢复的情况，就是陷阱；若有机会采取恢复措施并重新执行出错的指令，就是故障。例如，访问未映射的内存页会引发故障，地址合法时系统会获取相应页面及其内容并重新执行操作，地址不合法时进程会收到信号并终止；除以零是陷阱，进程会收到SIGFPE信号。
VAX异常处理程序可让虚拟内存系统处理缺失页面的故障，并向进程发送SIGFPE信号处理算术陷阱，这段代码从3BSD以来几乎未变。此外，在1980年，如今的一些信号名称与当时不同，如SIGILL当时叫SIGINS等。
Perl构建问题引发的调查
2002年4月下旬，负责OpenBSD基础系统中Perl相关工作的Todd Miller尝试编译最终成为Perl 5.8的最新Perl快照，发现它在i386和vax平台上无法构建，原因是miniperl有时会陷入死循环。他编写了独立复现程序，i386平台的问题很快解决，但Vax平台的问题依旧存在。
5月7日和一周后，OpenBSD开发者聊天室里有关于SIGFPE问题的状态汇报。第二天，作者加入讨论，提到从Linux - vax项目笔记中发现的问题，即遇到特定算术故障时，PC会回退到引发故障的指令处，若发送SIGFPE信号且无处理程序，程序会陷入无限循环。
作者写出可能解决问题的粗略补丁，问题在于若算术陷阱是故障且SIGFPE信号被忽略，需在出错指令之后恢复进程执行，但VAX异常模型无此能力，内核必须自行跳过该指令，而VAX指令长度可变，需对指令进行反汇编来计算长度。
大约6个小时后，作者想出不太优雅的解决方法，复用内核调试器中的部分反汇编代码。但该方法得到的反馈大多负面，于是作者重新修改代码，让skip_opcode函数完全独立于调试器代码，新版本补丁很快被合并。
这个修复方案在7年后被应用到NetBSD上，但两天后，Michael Hitch发现更改中的一个bug并修复了它。那么，在未来的内核开发中，还会遇到哪些类似的挑战呢？
