添加未执行代码致ARM内核崩溃：vector_swi调用C函数异常

我之前在ARM内核里做类似的用户态-内核态边界逻辑注入时，也踩过不少一模一样的坑。结合你描述的“简单逻辑正常、加额外代码就崩”的情况，大概率是这些细节没处理到位：

1. 寄存器上下文被破坏 #

ARM内核异常入口的寄存器状态是严格遵循调用约定的，vector_swi作为SWI异常的入口点，后续流程严重依赖当前寄存器的原始值。如果你的C函数没有妥善保存/恢复非临时寄存器，直接打乱了r4-r12这类需要保留的寄存器状态，后续内核流程必然崩溃。

• 修复方案：
  在调用C函数前，用汇编手动保存寄存器，调用完成后恢复：

  stmdb sp!, {r4-r12, lr}  @ 压栈保存非临时寄存器和链接寄存器
  bl your_custom_c_function
  ldmia sp!, {r4-r12, lr}  @ 弹栈恢复寄存器上下文
  

  或者给C函数添加编译器属性强制保存所有寄存器：

  void your_custom_c_function(void) __attribute__((preserves_all));
  

2. 内核栈溢出或非法访问 #

vector_swi刚进入异常时，内核栈的可用空间非常有限（仅保留了异常处理的基础栈帧）。如果你的额外代码里用了大量局部变量、递归调用，或者误访问了非法内存地址，很容易触发栈溢出或页错误，直接导致内核panic。

• 修复方案：
  • 把C函数里的大局部变量改成静态变量，减少栈空间占用；
  • 提前通过current_thread_info()确认当前内核栈的边界，避免越界；
  • 不要在这个早期异常路径里做复杂的内存分配、用户态地址访问操作。

3. 异常状态被非法修改 #

进入vector_swi时CPU处于SVC特权模式，此时中断掩码、MMU状态等系统参数都是为异常处理量身定制的。如果你的额外代码里修改了CPSR（比如开启了未预期的中断）、切换了地址空间，会直接破坏后续异常处理的基础环境。

• 修复方案：
  • 禁止在C函数里修改CPSR寄存器，如果必须操作中断，要先保存原始状态，调用结束后立即恢复；
  • 避免访问用户态虚拟地址——此时还未完成地址空间切换，用户态地址在内核态是不可访问的。

4. 编译器优化破坏调用约定 #

激进的编译器优化（比如O2/O3级别）可能会把C函数的变量放到寄存器里，或者重排指令逻辑，打破汇编与C代码之间的调用约定。这种情况下，哪怕代码逻辑本身没问题，也会因为寄存器乱序导致崩溃。

• 修复方案：
  给自定义C函数添加属性禁止内联和优化：

  void your_custom_c_function(void) __attribute__((noinline, optimize("O0")));
  

  同时查看编译后的汇编代码，确认寄存器使用符合ARM内核的调用规范。

快速排查步骤 #

1. 二分定位问题代码：把C函数精简回正常版本，然后逐行添加额外代码，每加一行就测试，精准定位触发异常的具体逻辑；
2. 内核调试回溯：用KGDB等调试工具挂接内核，查看异常发生时的寄存器状态、栈回溯信息，确认是寄存器破坏、栈溢出还是其他异常；
3. 对比汇编差异：对比正常版本与异常版本的编译后汇编代码，看编译器是否生成了不符合预期的指令。

内容的提问来源于stack exchange，提问作者Guru Prasad