手把手教你构建ARM64异常向量表：从零开始的系统级初始化实战
你有没有遇到过这样的场景？在一块全新的ARM64开发板上写好启动代码，满怀期待地烧录运行，结果程序刚跳转到C环境就“啪”一下死机了——没有打印、没有反应，甚至连JTAG都抓不到状态。
别急，这很可能不是你的main函数写错了，而是异常向量表没配对。
在x86世界里，我们习惯了中断描述符表（IDT）那一套复杂的门描述符和段选择子机制；但当你踏入ARM64的世界，会发现一切都变了：没有GDT，没有IDT，取而代之的是一个简单却极其严格的2KB固定大小的异常向量表，由VBAR_EL1寄存器指向它，CPU靠这个“地图”来响应每一次中断、系统调用或内存错误。
今天，我们就抛开理论堆砌，从第一行汇编开始，一步步搭建属于你的ARM64异常处理框架。无论你是想移植Bootloader、开发裸机固件，还是为将来写一个迷你操作系统打基础，这篇教程都会让你真正理解：当CPU说“我出问题了”，它到底该去哪找答案。
异常不是故障，是系统的呼吸节奏
先别急着敲代码。我们得明白一件事：现代处理器从来都不是一条直线跑到底的机器。它们总是在各种“意外”中切换上下文——用户程序发起系统调用、定时器触发中断、访问非法地址引发页错误……这些统称为异常（Exceptions），是操作系统得以运作的生命线。
ARM64把这种机制设计得极为结构化。它的异常模型围绕四个特权等级展开：
- EL0：用户程序，权限最低；
- EL1：操作系统内核，常规异常处理者；
- EL2：Hypervisor，用于虚拟化；
- EL3：安全监控，掌管安全与非安全世界切换。
当我们从EL0执行一条svc #0指令时，CPU并不会继续往下走，而是立即“升权”进入EL1，并根据当前有效的VBAR_EL1寄存器值，跳转到对应的异常向量入口。整个过程硬件自动完成，无需软件干预——前提是你已经把这张“跳转地图”准备好了。
否则，就像导航丢了坐标，CPU将跳入未知区域，系统就此崩溃。
所以，异常向量表的本质，就是一张预设好的异常路由表。它不处理具体逻辑，只负责第一时间接住CPU抛出的控制流，然后引导它进入正确的处理流程。
向量表长什么样？拆解那2KB的神秘空间
ARM64规定，每个异常级别的向量表必须是2KB（0x800字节）大小，并且起始地址必须2KB对齐（即低11位为0）。如果你往VBAR_EL1写了一个未对齐的地址，恭喜你，还没等异常发生，这条写操作本身就会触发异常。
这张2KB的表被划分为4个512字节的大块，每块对应一类异常来源：
| 块索引 | 来源说明 |
|---|---|
| 0 | 当前EL发生的同步异常（如SVC、未定义指令） |
| 1 | 当前EL的异步IRQ中断 |
| 2 | 当前EL的快速FIQ中断 |
| 3 | 当前EL的SError（系统错误） |
而每个大块内部又细分为4个128字节的小向量，用于进一步区分异常原因。例如，块0中的四个向量分别对应：
- SP选择为SP0时的同步异常
- IRQ
- FIQ
- SError
虽然标准允许这么多分支，但在大多数裸机系统中，我们通常只使用其中几个关键路径。比如：
- 用户态触发SVC → 跳转至
handle_sync_exception_el1 - 外部设备发出IRQ → 跳转至
handle_irq_el0
其余未使用的向量可以填充为空白或陷阱指令，防止误跳。
📌重点提醒：不要以为“我没用FIQ”就可以删掉相关块！整个2KB空间必须完整存在，哪怕只是用
.space填满。少一字节，系统就可能崩。
和amd64比一比：为什么ARM的设计更“嵌入式友好”？
如果你熟悉x86_64架构，可能会问：“这不就跟IDT差不多吗？”
表面上看确实功能类似——都是异常分发机制。但底层实现天差地别。
| 对比项 | ARM64 EVT | amd64 IDT |
|---|---|---|
| 结构形式 | 线性数组，直接跳转 | 描述符表，需查表解析 |
| 初始化复杂度 | 写一个对齐地址即可 | 需构造多个门描述符，设置段选择子 |
| 动态更新能力 | 弱（需刷新缓存） | 强（可用lidt重载） |
| 性能 | 极快，无额外内存访问 | 中等，涉及GDT/IDT多次查表 |
| 可移植性 | 高，统一映射方式 | 低，依赖段机制和保护模式 |
可以看到，ARM64的选择明显偏向简洁高效。它舍弃了x86那种灵活但臃肿的分段+门描述符机制，采用纯扁平化的向量布局。这对于资源受限的嵌入式系统来说是个巨大优势：你不需要花几十行代码去构造IDT条目，只需要一段对齐内存 + 一句msr vbar_el1, x0，就能让系统具备完整的异常响应能力。
这也体现了ARM设计理念的核心：用最简单的硬件支持，达成最可靠的系统行为。
开干！手写第一个向量表（vectors.S）
现在进入实战环节。我们要做的第一件事，就是在汇编中定义这块2KB的向量表。
创建文件vectors.S：
.section ".vectors", "ax" .align 11 // 必须2KB对齐 (2^11 = 2048) .global g_vector_table g_vector_table:接下来填充四个主块。我们重点关注常用路径：
第一块：当前EL同步异常（SVC、未定义指令等）
// Block 0: Current EL, SP0 — Synchronous b handle_sync_exception_sp0 b handle_irq_sp0 b handle_fiq_sp0 b handle_serror_sp0 .space 0x100 - (. - g_vector_table) // 填充至512字节这里我们暂时留空处理函数，后续再实现。注意.space指令确保这一块正好512字节。
第二块：当前EL使用SP_ELx的同步异常（典型内核态异常）
// Block 1: Current EL, SP_ELx — Synchronous b handle_sync_exception_el1 // 最常用：EL0触发SVC进入EL1 nop nop nop .space 0x200 - (. - (g_vector_table + 0x200)) // 补齐第二块这是最核心的一条：当用户程序执行svc指令时，CPU会跳到这里。
第三块：低级别EL的IRQ中断（如EL0收到外部中断）
// Block 2: Lower EL using AArch64 — IRQ b handle_irq_el0 // 外部中断入口 nop nop nop .space 0x300 - (. - (g_vector_table + 0x400))第四块：低级别EL的FIQ
// Block 3: Lower EL using AArch64 — FIQ b handle_fiq_el0 nop nop nop .space 0x800 - (. - g_vector_table) // 补全2KB至此，一个完整的向量表骨架已完成。虽然大部分跳转目标还未实现，但我们已经搭好了“高速公路”的路基。
C语言接管：从汇编跳入高级世界
向量表里的每一个b指令最终都要落地。我们希望尽快脱离汇编，进入C语言进行上下文保存和异常分类。毕竟，没人愿意用汇编写完所有寄存器压栈逻辑。
以最常见的handle_sync_exception_el1为例，在exception.S中添加：
.extern handle_exception_c handle_sync_exception_el1: stp x29, x30, [sp, #-16]! // 保存FP/LR stp x0, x1, [sp, #-16]! // ... 保存x2~x28 mrs x0, esr_el1 // 读取异常综合征 mrs x1, elr_el1 // 异常返回地址 mrs x2, spsr_el1 // 保存的状态 mov x3, sp // 当前上下文指针 bl handle_exception_c // 跳转C函数 ldp x0, x1, [sp], #16 ldp x29, x30, [sp], #16 eret // 返回原现场对应的C函数原型如下：
void handle_exception_c(uint64_t esr, uint64_t elr, uint64_t spsr, uint64_t *ctx);其中ctx指向保存的通用寄存器组。通过分析esr & 0x3F（低6位为异常类码），我们可以判断具体异常类型：
switch (esr & 0x3F) { case 0x25: // SVC from AArch64 do_syscall(ctx); break; case 0x3c: // IRQ taken to EL1 handle_irq(); break; default: panic("Unhandled exception class: %x\n", esr & 0x3F); }这样，我们就实现了从硬件异常 → 汇编入口 → C语言分发的完整链条。
初始化：把表挂上去！
有了向量表，还得告诉CPU它在哪。这就是VBAR_EL1寄存器的工作。
在C语言中完成初始化：
void init_exception_vectors(void) { extern char g_vector_table[]; uint64_t base = (uint64_t)&g_vector_table; // 检查对齐 if (base & 0x7FF) { panic("Vector table not 2KB aligned!"); } // 写入VBAR_EL1 __asm__ volatile ( "msr vbar_el1, %0\n" "dsb sy\n" // 数据同步屏障 "isb\n" // 指令同步屏障 : : "r"(base) : "memory" ); }两点关键细节：
dsb sy; isb不可省略：确保写操作对全局可见，并清空流水线，防止后续指令乱序执行。- 此函数应尽早调用，最好在启用MMU之前完成物理地址映射阶段的设置。若后期启用了虚拟内存，可重新加载高地址版本的向量表。
实战调试技巧：那些年踩过的坑
别以为写完就万事大吉。以下是新手最容易翻车的地方：
❌ 坑点1：忘了对齐，导致msr自陷
即使你在汇编里写了.align 11，链接器仍可能因为其他段的影响破坏对齐。解决办法是在链接脚本中强制指定：
SECTIONS { .vectors ALIGN(2048) : { KEEP(*(.vectors)) } > RAM }❌ 坑点2：向量表放在栈上或未分配内存区域
确保.vectors段被正确加载进RAM或ROM，并且有执行权限。如果使用QEMU模拟，记得检查加载地址是否匹配。
❌ 坑点3：未屏蔽中断导致早期中断风暴
在初始化完成前，建议关闭IRQ/FIQ：
__asm__ volatile ("msr daifset, #2" ::: "memory"); // 屏蔽IRQ待中断控制器（如GIC）配置完毕后再开启。
✅ 秘籍：加一个默认陷阱向量
对于未实现的异常路径，不要留成空跳转。加上：
b .让它陷入无限循环，便于调试器捕获。
完整系统中的位置：它如何支撑起一个OS雏形？
一旦异常机制跑通，你就拥有了构建操作系统的基石。典型的调用链如下：
[User App] svc #0 ↓ [Hardware] 切换至EL1，查VBAR_EL1 ↓ [Vector Table] 跳转 handle_sync_exception_el1 ↓ [Assembly Stub] 保存上下文，调用C handler ↓ [C Handler] 解析ESR → 发现是SVC → 查系统调用表 ↓ [Syscall Dispatcher] 执行 write() / exit() 等 ↓ [eret] 返回用户空间同样的路径也适用于：
- 定时器中断 → 触发调度器
- 缺页异常 → 实现虚拟内存
- 外设中断 → 调用驱动回调
可以说，异常向量表是连接硬件与软件的桥梁，也是所有现代操作系统的神经中枢。
写在最后：掌握它，你就掌握了系统的心跳
ARM64异常向量表看似只是一个小小的2KB数据块，但它承载的是整个系统的稳定性与可控性。相比amd64繁琐的IDT配置，ARM的设计更加直观、高效，尤其适合嵌入式开发者快速上手。
通过本文，你应该已经学会：
- 如何定义一个符合规范的2KB对齐向量表；
- 如何通过
VBAR_EL1将其注册给CPU； - 如何结合汇编与C语言实现上下文切换与异常分发；
- 如何避免常见初始化陷阱。
下一步，你可以尝试：
- 接入GIC实现多核中断分发；
- 添加对VBAR_EL2/EL3的支持；
- 在异常处理中加入栈回溯功能辅助调试。
如果你正在做Raspberry Pi、Allwinner、Rockchip或其他ARM64平台的底层开发，这套机制几乎是绕不开的一关。现在，你已经有能力亲手点亮它了。
如果你在实现过程中遇到了挑战，欢迎留言交流。毕竟，每一个成功的
eret背后，都曾有过无数次停在.space里的沉默。
