异常控制流

一、第一性原理：为什么需要异常控制流

1. 顺序控制流的假设与局限

经典程序模型假设：

但真实计算机系统中，存在大量无法由顺序控制流表达的情形：

场景 顺序控制流的问题
I/O 设备完成 程序无法轮询所有设备
外部中断 程序无法预测发生时间
错误与异常 错误发生点不可控
系统调用 必须跨越权限边界

👉 结论（第一性原理）：

顺序控制流不足以描述“被动、抢占、跨层”的控制转移。

2. 异常控制流的本质定义

异常控制流（ECF） 是一种由硬件或系统触发的、非程序显式指定的控制权转移机制， 用于在不可预测或必须立即处理的情况下打断当前指令流。

异常不是“错误”，而是：

二、统一模型：异常控制流在系统中的位置

1. 控制流的完整分类

控制流（Control Flow）
├── 顺序控制流（Normal Flow）
│   └── 函数调用 / 返回
└── 异常控制流（Exceptional Flow）
    ├── 异步异常（中断）
    └── 同步异常
        ├── 陷阱（Trap）
        ├── 故障（Fault）
        └── 终止（Abort）

👉 这是稳定认知模型，独立于具体 CPU / OS 实现。

2. 指令级抽象：I_curr 与 I_next

异常的本质差异，体现在：

异常返回时，控制权究竟回到哪里？

三、异常的系统级执行模型（硬件 → 软件）

graph TD
App[应用程序执行] --> Icurr[I_curr]
Event((异常事件发生)) -.-> Icurr

Icurr -- 控制权抢占 --> Handler[异常处理程序]
Handler --> Decision{是否返回?}

Decision -- 返回 --> Inext[I_next]
Decision -- 不返回 --> Terminate[进程终止]

Inext --> Continue[继续执行程序]

关键认知点

四、异常 ≠ 函数调用（架构级对比）

异常常被类比为“函数调用”，但这只在表象层成立。

维度 函数调用 异常
触发主体 程序显式 硬件 / OS
是否可预测 可预测 不可预测
控制权 调用方 被抢占
栈 用户栈 用户栈 / 内核栈
返回点 唯一 I_curr / I_next / 不返回

👉 结论：

函数调用是协作式控制转移， 异常是抢占式控制转移。

五、异常处理的系统机制

1. 异常表（Exception Table）

graph LR
subgraph ExceptionTable [异常表]
E0 --> H0
E1 --> H1
E2 --> H2
En --> Hn
end

👉 异常表是硬件与操作系统之间的稳定接口。

2. 异常发生时，系统必须完成的三件事

  1. 保存上下文

    • 所有通用寄存器
    • 程序计数器

  2. 切换执行环境

    • 用户态 → 内核态
    • 用户栈 → 内核栈

  3. 决定返回语义

    • 是否返回
    • 返回到哪里

六、异常的四种基本类型（统一抽象）

类型 触发原因 同步性 返回行为 本质
中断 I/O 设备 异步 总是 I_next 外部事件通知
陷阱 程序主动 同步 总是 I_next 服务请求
故障 可修复错误 同步 I_curr 或终止 延迟完成
终止 不可修复错误 同步 不返回 系统一致性保护

七、典型异常流程（认知验证）

1. 中断：异步抢占

👉 用于响应外部世界

2. 陷阱（系统调用）

👉 是受控的异常

3. 故障（Fault）

👉 本质是**“延迟完成”**

4. 终止（Abort）

八、Linux / x86-64 中的异常（概念映射）

异常 抽象类型 是否返回 含义
除法错误 终止 否 指令语义非法
缺页 故障 是 地址映射延迟
一般保护故障 终止 否 权限/一致性破坏
机器检查 终止 否 硬件不可恢复错误

👉 这些只是抽象模型的具体实例。

九、用户态的异常控制流：非本地跳转

1. setjmp / longjmp 的本质

int setjmp(jmp_buf env);
void longjmp(jmp_buf env, int val);

setjmp / longjmp 是在用户态模拟异常控制流的机制

它们实现了：

2. 与硬件异常的本质对比

维度 硬件异常 setjmp / longjmp
触发 硬件 程序
上下文保存 自动 人工
安全性 高 低
可维护性 强约束 易破坏结构

👉 它们揭示了： 异常控制流是一个通用思想，而不仅是硬件特性。

关联内容（自动生成）