企业官网建设流程全解析

1. 异常处理的整体框架与设计思路

搞ARMv8-A底层开发的人，迟早都要过异常处理这一关。我最初接触这块的时候，看到架构手册里那一大堆术语——Exception Levels、Synchronous Exception、Vector Table、ESR_EL1、SPSR_EL1，说实话头皮发麻。但真正动手写了几次异常处理代码、调了几个难缠的bug之后，才发现这东西的框架设计其实非常优雅，理解了内核设计者的思路，后面所有细节都能串起来。

ARMv8-A的异常处理，本质上解决的是这么一个问题：CPU在跑主流程的时候，突然遇到了一件需要特殊处理的事，比如外部中断来了、内存访问出错了、遇到了未定义指令，这时候CPU需要暂停当前工作，跳到一个专门的地方去处理这件事，处理完再回来继续原来的工作。整个过程要保证三点：现场不能丢、跳转要快、回来要准。“现场不能丢”指的是寄存器状态、程序状态字这些关键信息必须保存好；“跳转要快”指的是从异常发生到进入处理函数这条路径上不能有太多额外开销；“回来要准”指的是处理完之后能精确恢复到异常发生之前的状态。

ARMv8-A解决这三个问题的思路，可以概括成“分级 + 向量表 + 寄存器现场保存”这套组合拳。

先说分级。ARMv8-A引入了Exception Levels，通俗讲就是四个特权等级，EL0到EL3。EL0是用户态，跑普通应用程序；EL1通常是内核态，跑操作系统内核；EL2是虚拟化层，跑Hypervisor；EL3是最高特权层，跑安全固件。这种分级设计的直接好处是隔离——用户程序崩了不会直接把整个系统拖垮，因为它在EL0，访问不了EL1的资源。异常可以从低Level往高Level走，比如EL0的应用程序触发了系统调用，会陷入EL1的内核去处理；也可以在同一Level内部处理，比如EL1内核代码访问了非法地址，产生异常后仍在EL1同步处理。这种设计保证了“低特权级的错误不能破坏高特权级的代码”，是整个系统稳定性的基石。

再说向量表。ARMv8-A要求每个异常Level都准备一张异常向量表（Vector Table），这张表规定了异常发生后CPU跳转的目标地址。但ARMv8-A的向量表不是简单的一列地址，它分成了四组，每组又包含四个entry，总共十六个entry。为什么这么复杂？因为异常来源不同，处理策略也不同。四组分别对应：当前EL使用SP_EL0的异常、当前EL使用SP_ELx的异常、更低EL运行AArch64时的异常、更低EL运行AArch32时的异常。每组里的四个entry分别对应：Synchronous异常、IRQ、FIQ、SError。这个设计的精髓在于，CPU不需要额外判断“我是谁、我在哪”，直接根据当前状态跳转到对应的entry，省去了大量运行时判断，异常入口延迟被压到了极致。

最后说寄存器现场保存。ARMv8-A的通用寄存器有31个（X0-X30），加上SP、PC、SPSR、ELR这些系统寄存器。异常发生时，硬件自动帮你做了一部分保存工作：PC被保存到ELR_ELx，处理器状态被保存到SPSR_ELx，然后CPU切到目标EL的SP。但剩下的31个通用寄存器，硬件不管，必须由软件自己保存。这就是为什么每个异常处理函数开头都是一大堆STR指令——把X0到X30全部压栈。我之前见过有人偷懒，只保存部分寄存器，结果异常处理函数内部一调用子函数，通用寄存器被改写，回来之后主流程的变量全乱了，那种bug极其难查。

这套设计在业界有一个很形象的类比：异常处理就像医院的分诊台。分诊台根据病人的情况（异常类型）和病人的身份（当前EL和SP选择），直接引导到不同的科室（向量表entry），而不是让每个病人都先排队做全套检查再决定去哪。硬件帮你做了最紧急的预处理（保存PC和PSTATE），剩下的诊断和治疗交给专科医生（异常处理函数）。

2. 核心机制逐层拆解：从异常类型到向量表布局

2.1 异常类型的判定：Synchronous、IRQ、FIQ、SError

ARMv8-A把异常分为四大类，理解这四类的区别是写处理代码的前提。

• Synchronous（同步异常）：这一类是“指令执行时产生的异常”，它的特点是异常发生后，异常处理函数可以通过ESR_ELx寄存器精确知道是哪条指令、哪个操作导致的。同步异常包括：未定义指令、SVC/HVC/SMC系统调用指令触发的异常、数据异常（内存访问出错）、指令异常（取指出错）、调试异常等。同步异常在处理的时候有个关键特性：异常返回地址ELR_ELx指向的是触发异常的指令本身，而需要开发者根据场景决定是否需要重新执行这条指令或者跳过它。

• IRQ（普通中断）：这是异步异常，由外部硬件触发，和当前正在执行的指令没有直接关系。IRQ的特点是“随机性”——你不知道它什么时候来，所以处理IRQ的第一要务是尽快保存现场，然后判断是哪个外设发出的中断，调用对应的中断服务程序。ARMv8-A的IRQ可以被PSTATE.I位屏蔽。

• FIQ（快速中断）：优先级比IRQ更高，在ARMv8-A里FIQ通常被用于安全世界或对延迟极其敏感的场景。相比传统ARM的FIQ设计，ARMv8-A在寄存器层面并没有给FIQ单独预留影子寄存器组，它的“快”更多体现在软件分层上：比如在EL3用FIQ处理安全监控调用。

• SError（系统错误）：这是异步的系统级错误，比如总线上出现了无法纠正的错误、缓存一致性出了问题。SError的处理通常比较棘手，因为它不像同步异常那样能精确定位到某条指令，你只能在较高层面做系统状态检查和恢复。

从开发者的角度看，最常见的是同步异常和IRQ。我在实际项目中，花了大量精力在同步异常上，因为这一类异常处理得好不好，直接决定了系统出错后是“优雅地降级”还是“直接挂死”。

2.2 向量表的布局细节：为什么是16个entry

ARMv8-A的向量表布局，我建议初学者一定要亲手画一遍。它每个Level都有独立的向量表，基地址由VBAR_ELx寄存器指定。向量表中每个entry占128字节（32条指令），16个entry共计2048字节，2KB对齐。

这16个entry的排布顺序是固定的，我不能随意调整：

为什么把Synchronous放在每组的最前面？我个人的理解是，同步异常需要软件马上读取ESR_ELx来判定具体原因，放最前面既符合直觉也方便查表。IRQ和FIQ排在后面，SError在最后。这种排布在Linux内核、各类RTOS里都是直接照此实现的，没有例外。

每个entry只有128字节，通常放不下完整的处理逻辑，所以实际操作中entry里放的是一条跳转指令，跳到真正的处理函数。例如：

.balign 128 vector_cur_el_sp_el0_sync: b sync_exception_handler

这里有个容易被忽略的细节：.balign 128。因为向量表的entry大小是128字节，如果上一个entry里的指令没填满128字节，必须用对齐指令补齐，否则后续entry的起始地址就错了，一旦异常发生会跳到一个错位的地方，大概率直接挂机。我见过不止一次有人在这里踩坑——向量表整体2KB对齐没问题，但内部entry没做128字节对齐，结果异常一来跳到了未知地址。

2.3 异常入口的硬件自动行为

异常发生时，硬件会自动做以下几件事，理解这个顺序对写入口汇编至关重要。

第一步，硬件将当前PC的值保存到目标EL的ELR_ELx寄存器。这里有个细节值得注意：异常发生时程序当前正在执行的指令，其地址会被完整保存。对于同步异常，这条指令就是触发异常的指令；对于IRQ等异步异常，这条指令是中断发生时正在执行的任意指令。

第二步，硬件将当前PSTATE保存到SPSR_ELx。PSTATE包括条件标志位N/Z/C/V、异常屏蔽位D/A/I/F、当前EL字段、栈指针选择位SPS等。这些信息是异常返回时恢复CPU状态的依据。

第三步，硬件根据异常类型和目标EL，自动更新PSTATE：D/A/I/F屏蔽位全部置1，也就是进入异常后默认屏蔽所有其他异常；EL字段更新为目标EL；SPS字段根据异常来源更新为合适的值。这意味着什么？意味着在异常处理的最开始阶段，你是处在“中断屏蔽”状态下的，不会嵌套被打断。等现场保存完之后，如果你想要响应更高优先级的中断，需要软件显式地清除对应的屏蔽位。

第四步，硬件将PC设置为向量表基地址加上对应entry的偏移，开始执行异常处理代码。

整个自动过程不需要软件参与，速度极快。这就是ARMv8-A异常入口低延迟的关键。你不需要像一些老架构那样，在异常处理开头去手动拼接PC和PSTATE的保存，硬件已经用ELR_ELx和SPSR_ELx两个专用寄存器搞定了。

2.4 异常返回的对称操作：ERET

有入口就有出口。ARMv8-A提供了ERET指令专门用于异常返回。ERET指令的执行效果是：把SPSR_ELx恢复为PSTATE，把ELR_ELx写入PC。执行完ERET之后，CPU就回到了异常发生之前的状态继续运行。

这里有一个我反复强调的坑：ERET必须在正确的EL下执行。你进入异常时到了EL1，返回时必须在EL1执行ERET。如果你在EL1处理异常的过程中，调用了某个函数切换到了别的EL，再执行ERET，行为将不可预测。我们一般要求异常处理函数入口和返回严格配对，不要在里面乱切换Level。

另外要注意，ERET恢复的PSTATE包含了之前被置位的异常屏蔽位。也就是说，如果进入异常时IRQ是被屏蔽的（PSTATE.I=1），返回后IRQ仍然是屏蔽的。所以不要在异常处理函数里假设“返回主流程后中断就自动开启了”，主流程的PSTATE是什么样就是什么样，硬件原样恢复。

3. 实操：在EL1搭建一套最小可用的异常处理框架

3.1 准备向量表与异常栈

搭建异常处理框架的第一步是定义向量表。我用的是汇编实现，这样可以精确控制每个entry的布局。

.section .text.vectors, "ax" .balign 0x800 .global exception_vector_base exception_vector_base: // 当前EL，SP_EL0 .balign 128 b exception_sp0_sync .balign 128 b exception_sp0_irq .balign 128 b exception_sp0_fiq .balign 128 b exception_sp0_serror // 当前EL，SP_ELx .balign 128 b exception_spx_sync .balign 128 b exception_spx_irq .balign 128 b exception_spx_fiq .balign 128 b exception_spx_serror // 更低EL，AArch64 .balign 128 b exception_lower_64_sync .balign 128 b exception_lower_64_irq .balign 128 b exception_lower_64_fiq .balign 128 b exception_lower_64_serror // 更低EL，AArch32 .balign 128 b exception_lower_32_sync .balign 128 b exception_lower_32_irq .balign 128 b exception_lower_32_fiq .balign 128 b exception_lower_32_serror

向量表准备好了之后，编译的时候有两个硬性要求。第一，向量表起始地址必须2KB对齐，我用了.balign 0x800。第二，链接时要保证这段代码被放在可执行内存中，并且运行时用MSR VBAR_EL1, x0指令把基地址写进VBAR_EL1寄存器。

异常栈的分配也很关键。ARMv8-A的异常入口，硬件会自动切换到目标EL的SP。如果之前EL1内核主流程用的是自己的栈，异常来了之后应该换到专门的异常栈，而不是复用当前栈。为什么？因为异常可能在栈指针被临时破坏的情况下发生，如果还用同一个栈，可能连保存现场都做不到。实践中，我们一般预先分配一块独立内存区域作为异常栈，在系统初始化的时候做好记录，异常入口处直接用LDR x0, =exception_stack_top加载栈顶，再MOV sp, x0切换。

3.2 保存现场与读取异常原因

异常入口做的第一件事是保存现场。这里我采取的做法是：先把所有通用寄存器压栈，再保存ELR_EL1和SPSR_EL1，最后读取ESR_EL1判断异常类型。

exception_spx_sync: // 保存现场 stp x0, x1, [sp, #-16]! stp x2, x3, [sp, #-16]! stp x4, x5, [sp, #-16]! stp x6, x7, [sp, #-16]! stp x8, x9, [sp, #-16]! stp x10, x11, [sp, #-16]! stp x12, x13, [sp, #-16]! stp x14, x15, [sp, #-16]! stp x16, x17, [sp, #-16]! stp x18, x19, [sp, #-16]! stp x20, x21, [sp, #-16]! stp x22, x23, [sp, #-16]! stp x24, x25, [sp, #-16]! stp x26, x27, [sp, #-16]! stp x28, x29, [sp, #-16]! stp x30, xzr, [sp, #-16]! mrs x0, elr_el1 mrs x1, spsr_el1 stp x0, x1, [sp, #-16]! mrs x2, esr_el1 stp x2, xzr, [sp, #-16]!

为什么用stp成对压栈？ARMv8-A的STP指令可以一次存两个64位寄存器，比逐条STR少一半的开销。异常入口是性能敏感路径，这一点点优化也要做。另外注意stp x30, xzr这里，x30是链接寄存器LR，异常入口处必须保存，因为异常处理函数内部一旦执行BL调用子函数，x30就会被改写。

接下来读取ESR_EL1，它的低26位是EC字段（Exception Class），表示异常类别。我常用的一张速查表是这样的：

对于数据异常，还需要进一步解析DFSC字段和FAR_EL1寄存器。FAR_EL1保存了触发数据异常的虚拟地址，这对定位代码bug特别关键。比如你解引用了一个空指针，FAR_EL1就是你解引用的那个地址，一般就是0或者接近0。

3.3 分发处理与恢复现场

读取异常原因后，就是分发处理。我一般用EC值做switch-case，每个case对应一个处理函数。

void handle_sync_exception(uint64_t esr, uint64_t elr, uint64_t far) { uint64_t ec = esr >> 26; switch (ec) { case 0x15: // SVC handle_svc(); break; case 0x01: // 未定义指令 handle_undef_instr(elr); break; case 0x21: { // 数据异常 uint64_t dfsc = esr & 0x3F; if (dfsc == 0x04 || dfsc == 0x08) { // 翻译页错误，缺页 handle_page_fault(far); } else { handle_data_abort(esr, far); } break; } default: // 未知异常，打印错误信息并挂起 panic(esr, elr, far); } }

这里有个细节：EC为0x21的数据异常，DFSC里包含了具体的内存错误原因。0x04是“Translation fault，level 0”，0x08是“Translation fault，level 1”，以此类推，常见的还有0x05、0x09、0x0D表示不同level的页表翻译错误。缺少经验的开发者看到DFSC值，往往不知道如何定位问题。实际上DFSC的最后一位如果是奇数，通常代表某个页表项权限不符；如果是偶数，通常是页表项不存在。这个规律在排查问题的时候非常实用。

异常处理完成后，就要恢复现场并返回。恢复现场是保存现场的反操作，顺序非常重要，不能反：

ldp x2, xzr, [sp], #16 ldp x0, x1, [sp], #16 msr elr_el1, x0 msr spsr_el1, x1 ldp x0, x1, [sp], #16 ldp x2, x3, [sp], #16 ldp x4, x5, [sp], #16 ldp x6, x7, [sp], #16 ldp x8, x9, [sp], #16 ldp x10, x11, [sp], #16 ldp x12, x13, [sp], #16 ldp x14, x15, [sp], #16 ldp x16, x17, [sp], #16 ldp x18, x19, [sp], #16 ldp x20, x21, [sp], #16 ldp x22, x23, [sp], #16 ldp x24, x25, [sp], #16 ldp x26, x27, [sp], #16 ldp x28, x29, [sp], #16 ldp x30, xzr, [sp], #16 eret

这里有个核心原则：在ERET之前，必须先把ELR_EL1和SPSR_EL1恢复好。因为ERET指令执行时读取的就是这两个寄存器。如果你先执行了一堆通用寄存器的恢复，再顺手改掉了ELR_EL1，那么ERET就会返回到一个错误地址。我在实际项目中见过不止一次这种bug，现象是异常返回后PC乱跳，整个系统直接跑飞。

还有一个技巧：保存现场和恢复现场时，尽量少用x0-x18这些临时寄存器以外的寄存器来传参，因为异常处理函数可能会用这些寄存器。如果需要传参给C函数，我一般把ESR、ELR、FAR通过x0、x1、x2传入，这正好符合ARM64 C函数的参数传递规则。

4. 中断处理：从IRQ触发到中断服务程序

4.1 IRQ的入口处理与中断控制器交互

IRQ作为异步异常，处理路径和同步异常有显著区别。同步异常是执行某条指令时立刻触发的，你可以在异常处理函数里通过ESR精确定位；IRQ则是外部信号触发，你只能知道是哪个中断控制器（比如GIC）发出的，具体是哪个外设还需要去中断控制器里查询。

IRQ入口的现场保存和同步异常完全一样，这里不再重复。区别在于保存完现场之后，不是去读取ESR，而是去操作中断控制器。

以常用的GIC（Generic Interrupt Controller）为例，CPU收到IRQ后，要执行以下步骤：

1. 读取GICC_IAR寄存器，获取中断号。
2. 根据中断号，找到对应的中断服务程序（ISR）。
3. 执行ISR。
4. 写GICC_EOIR寄存器，通知中断控制器本次中断处理完成。

void handle_irq(void) { uint32_t iar; uint32_t irq_num; iar = read_gicc_iar(); irq_num = iar & 0x3FF; // 中断号在低10位 if (irq_num == 1023) { // 伪中断（Spurious Interrupt），直接返回 return; } isr_table[irq_num](); write_gicc_eoir(iar); }

中断号1023是GIC规定的伪中断，表示“当前没有真正的中断要处理”。这种情况一般出现在中断被关闭或者中断线信号抖动时。处理伪中断的原则很简单——什么都不做，直接返回。

读IAR这个操作在GIC的语义里还有一个隐含的副作用：读操作本身会让GIC确认中断，也就是把对应中断的状态从pending变为active。所以顺序很重要，必须先读IAR再执行ISR，不能反过来。

4.2 中断嵌套与优先级管理

ARMv8-A的异常入口默认屏蔽所有异常（PSTATE的A/I/F位都被置1）。如果你不希望处理IRQ的过程中被打断，保持默认状态即可。但有些低延迟场景需要中断嵌套，也就是在A中断处理过程中允许B中断插入，前提是B的优先级更高。

实现中断嵌套的做法是：在保存现场、清中断屏蔽位之后，重新开中断，让更高优先级的中断能够进来。这个“重新开中断”的操作是通过修改PSTATE实现的：

// 保存完现场之后，重新使能IRQ msr daifclr, #2 // 清除I位，使能IRQ

注意这里只清了I位（IRQ屏蔽位），没有清F位（FIQ屏蔽位）和A位（SError屏蔽位）。如果你希望在嵌套时也响应FIQ，就还需要清F位。但是，嵌套中断的处理复杂度会指数级上升，你需要保证每个嵌套层级的现场保存和恢复是独立的，栈空间也要预留足够。我个人建议，除非有明确的实时性指标要求，否则不要轻易开嵌套。

4.3 调度器与中断返回的特殊处理

在带操作系统的环境下，IRQ返回和普通的异常返回有一个重大区别：中断处理过程中可能发生了任务切换。比如，一个高优先级任务被中断唤醒了，调度器决定让这个新任务运行，而不是回到被中断的那个任务。

这种情况下，直接执行ERET返回原来的上下文就是错误的。正确的做法是：在中断处理结束时，检查调度器的need_resched标志，如果需要调度，则放弃当前任务的上下文，转而切换到新任务。

这里涉及一个关键概念——“中断返回不一定回到原来的地方”。实现上，很多内核的做法是，在IRQ处理的最后一步，把当前任务的SP保存到任务控制块中，然后加载新任务的SP，最后通过ERET返回到新任务的上下文。这样，被中断的任务在下一次被调度到时，会从它被打断的地方继续执行。

我刚开始做这个的时候特别困惑，总觉得ERET的语义就是“回到异常发生点”，后来才明白，只要你修改了栈指针或ELR_EL1寄存器，ERET就会回到你修改后的位置。调度器切换本质上就是改写这两个东西。理解了这一点，再看内核代码里的context switch，其实就不神秘了。

5. 异常处理中的常见问题与排查实录

5.1 异常向量表未生效或错位

这是最常见的低级错误，但排查起来往往很费劲。症状是系统一触发异常就跳飞到未知地址，或者压根没有进入我们预期的处理函数。

我排查这个问题的固定思路是：

• 先确认VBAR_EL1寄存器是否设置成功。用调试器读一下VBAR_EL1，看它的值是不是你代码里向量表的链接地址。
• 再确认向量表的对齐。用readelf -s查一下exception_vector_base的符号地址，看最低11位是否全为0（2KB对齐）。
• 最后确认每个entry的128字节对齐。如果对齐不正确，CPU跳转时会错开到错误的位置。

提示：向量表一旦编译进固件，链接地址就固定了。如果代码段启用了MMU，还要注意VBAR_EL1里应该写的是虚拟地址还是物理地址。在启用MMU之后，VBAR_EL1写的是虚拟地址。

5.2 ESR解析错误导致误判异常类型

ESR_EL1的EC字段是异常分类的关键。我踩过的一个坑是：AArch64状态下的SVC指令，EC值是0x15；但如果你在AArch32状态下调用SVC，EC值完全不同。所以异常处理函数里做switch-case时，一定不能假设所有来源都是AArch64。

还有一个容易混淆的点：数据异常（EC=0x21）时，ESR的ISS字段前两位（bit[5:4]）表示异常类型是读操作还是写操作。0b00是读，0b01是写，0b10是“操作码获取”。有时候系统报了一个数据异常，日志却没记录是读还是写，排查的时候无从下手。我一般在打印错误信息时会把整个ESR完整打印出来，而不是只打印EC。

5.3 ERET返回地址错误：ELR_EL1被改写

异常处理过程中不小心改写了ELR_EL1，是ERET后PC跑飞的头号原因。

我遇到过一个案例：一个异常处理函数在最后调用了某个调试打印函数，这个函数内部碰巧写了ELR_EL1（为了临时跳转），异常返回时直接回到了一个非法地址。这类问题用调试器的hardware breakpoint去监视ELR_EL1的写入，是最快的定位手段。在调试器里设wp ELR_EL1, w1，就能抓出是谁在写这个寄存器。

5.4 嵌套异常导致的栈溢出

开了中断嵌套之后，如果每个嵌套层都保存一套完整的寄存器上下文（31个通用寄存器 + ELR + SPSR + ESR，大概68个64位寄存器，合计544字节），深度嵌套时栈消耗相当可观。

我建议在启动阶段就做一个“栈水印”检查：把整个异常栈区预先填充0xAA，运行一段时间后检查水印被冲掉了多少，以此估算实际栈使用量。如果水印几乎全被冲掉，就要加大栈空间或者限制嵌套深度。

5.5 数据异常（Data Abort）的FAR_EL1与DFSC联合分析

数据异常是所有异常类型里信息量最大的，也是最需要联合分析才能定位问题的。

有一次我在调试一个内核模块，总是随机出现数据异常，有时候一次运行能跑几个小时才崩，有时候刚启动就崩。我通过打印FAR_EL1，发现崩溃地址总在某个固定地址附近波动，再结合DFSC是0x04（Translation fault, level 0），判断是页表项错误。最后查下来，是某个驱动在初始化时错误地修改了页表项，导致某个固定虚拟地址在特定条件下指向了非法物理页。

排查数据异常时，我的建议是：别只看ESR，一定要把FAR_EL1、ELR_EL1、SPSR_EL1三位一体打印出来。FAR告诉你“访问了哪个地址”，ELR告诉你“是哪条指令访问的”，SPSR告诉你“当时CPU处于什么状态”。三个信息合在一起，绝大多数数据异常都能定位。

6. 实操心得：几个容易被忽略的细节

矢量表对齐、现场保存完整、ERET之前恢复ELR和SPSR，这些是大家都知道的。我这里再补充几个我实际项目里踩过的、比较隐蔽的细节。

第一个是异常处理函数内部的编译选项。如果你用C语言写异常处理函数，务必给它们加no_instrument_function属性，或者放在编译时关闭了“函数插桩”选项的编译单元里。如果开启了插桩，编译器会在每个函数入口额外插入一段调用计数的代码，这段代码本身就可能触发异常（比如栈保护），导致递归进入异常处理，直接死循环。

第二个是异常栈的初始化时机。有些系统在启动阶段没有设置异常栈就开了中断，一旦中断进来，SP还是某个未初始化的值，现场保存直接写到非法内存。正确做法是：在初始化向量表之前，就要把异常栈设置好。

第三个是ERET的隔离性。在ARMv8-A里，ERET不仅会恢复PC和PSTATE，还会有一个流水线冲刷效果。这意味着ERET之后，CPU预取的指令全部作废，从新的PC重新开始取指。这个特性你不需要主动做什么，但心里要清楚——如果在异常处理函数末尾依赖某种顺序执行假设，可能会被ERET的冲刷打破。

第四个是SPSel位的影响。异常入口默认会把SP切换到目标EL的专用SP，也就是SPSel设为1。如果你的内核主流程大量使用SP_EL0，异常处理就必须在入口明确切换到SP_ELx对应的栈，否则会用到异常的SP_EL0，导致栈混乱。检查PSTATE的SPS位是排查栈相关异常的首选。

最后分享一个调试技巧：在异常处理入口加一个专用的“异常计数”变量，每次进入异常就加1。当系统出现“异常风暴”（比如外设持续触发中断，系统一直在处理中断没时间做正事）时，这个计数器会暴涨。我在排查一个“系统看似卡死”的问题时，就是靠这个计数器发现系统其实一直在处理中断，而不是死循环。

7. 异常处理框架的测试与验证方法

框架写完之后怎么验证？不能只靠跑业务功能碰运气。我建议做一轮系统的异常注入测试——故意制造各种异常，确认处理函数都正确响应。

同步异常测试比较简单：执行一条未定义指令，比如.word 0xDEADBEEF，确认CPU进入未定义指令异常处理函数。执行SVC指令，确认进入系统调用处理路径。访问一个非法地址，确认触发数据异常并打印出正确的ESR和FAR。

IRQ测试需要配合中断控制器。在开发板上用定时器中断做测试比较好，因为定时器中断可以精确控制触发频率。我的步骤是：初始化一个周期性定时器中断，然后在中断处理函数里翻转一个GPIO，用示波器看GPIO波形。如果波形频率稳定，说明中断路径通畅，反之则需要检查中断控制器配置。

SError和FIQ的测试比较麻烦，因为这两个异常的触发源通常比较特殊。在开发阶段，可以先在向量表的SError和FIQ入口放一个“未实现”标志，一旦触发就打印告警，确保这两个入口不会被意外触达。如果业务场景确实需要处理FIQ（比如在EL3处理安全中断），那就要单独做一套完整的测试用例。

测试用例设计参考表：

每一轮测试跑完之后，我建议把异常计数的变化和异常日志结合起来分析，做一个简单的回归清单。毕竟异常处理框架是系统的“最后一道防线”，它要是出了问题，整个系统的可靠性都无从谈起。