异常处理编译与栈展开

void f() {
    std::string s = "resource";      // 需要在异常时析构
    std::lock_guard<std::mutex> g(m); // 需要在异常时解锁
    may_throw();                      // 可能抛出
    use(s);
}

// setjmp 方案：进入作用域时保存现场，正常路径也要执行
jmp_buf env;
if (setjmp(env) == 0) {
    may_throw();          // 正常路径：这里付出了一次现场保存
} else {
    handle_error();
}

# 表驱动方案：正常路径只有一次调用，没有额外指令
call may_throw
# 异常发生时才去查 .eh_frame 表，找到当前 PC 对应的展开信息

阶段一（搜索）：
  从抛出点向上遍历栈帧，逐帧查 .eh_frame 与 .gcc_except_table
  找到第一个能处理该异常的帧，记录其 landing pad 地址
  若遍历到栈顶仍未找到，调用 std::terminate

阶段二（清理）：
  再次从抛出点向上遍历到捕获帧
  对每一帧执行其清理代码（析构局部对象）
  最后跳转到捕获帧的 landing pad，异常对象作为参数传入

# 一个函数对应的 CFI 指令（示意）
    .cfi_startproc
    pushq %rbp
    .cfi_def_cfa_offset 16        # CFA = rsp + 16
    .cfi_offset %rbp, -16         # rbp 的旧值存在 CFA-16
    movq %rsp, %rbp
    .cfi_def_cfa_register %rbp    # CFA 改用 rbp 计算
    subq $32, %rsp
    ...
    .cfi_endproc

.eh_frame 中每个 FDE（帧描述条目）的结构：
  PC 起始地址 -> 函数起始
  PC 范围     -> 函数长度
  CFI 指令流  -> 如何从当前帧走到调用者帧

// 展开器的简化逻辑
void unwind_search(void *throw_pc) {
    void *pc = throw_pc;
    while (pc) {
        Frame f = lookup_fde(pc);              // 查 .eh_frame
        if (!f.valid) { std::terminate(); }    // 信息缺失
        LSDA lsda = lookup_lsda(f);            // 查 .gcc_except_table
        LandingPad lp = match_handler(lsda, current_exception);
        if (lp.found) { return lp.address; }   // 找到捕获点
        pc = f.caller_pc();                    // 继续向上
    }
}

// 源
void f() {
    A a;                  // 需要析构
    try { g(); }
    catch (const E& e) { handle(e); }
}

; 编译器生成的 landing pad（简化）
lpad:
  %lp = landingpad { ptr, i32 } cleanup catch ptr @_ZTI1E
  ; %lp 的第一个分量是异常对象，第二个是「动作选择」
  switch i32 %lp.action, label %resume [
    i32 0, label %cleanup          ; 清理路径
    i32 1, label %catch_handler    ; 捕获路径
  ]
cleanup:
  call void @_ZN1AD1Ev(%a)          ; 析构 a
  resume { ptr, i32 } %lp           ; 继续向上抛
catch_handler:
  call void @handle(ptr %lp.exception)
  br label %exit

# 观察真实的异常表与 landing pad
clang++ -S -O1 -fexceptions f.cpp -o f.s
objdump -d --section=.text f.o | grep -A10 landingpad
readelf --debug-dump=frames f.o | head -40      # 看 CFI

void f() {
    A a;
    B b;              // b 构造后抛出：只需析构 b
    may_throw_1();
    C c;              // c 构造后抛出：需要析构 c、b、a
    may_throw_2();
}

清理路径合并：
  pad_1 -> 析构 b -> 析构 a -> resume
  pad_2 -> 析构 c -> 析构 b -> 析构 a -> resume
  合并后：
  pad_1 -> [b] ---------------------> 公共尾 -> resume
  pad_2 -> [c] -> [b] -> 公共尾（析构 a）-> resume

托管运行时的展开要求：
  1. 每个栈帧都有「栈图」描述哪些槽位是对象引用
  2. 展开到某帧之前，该帧的引用仍算作根
  3. 清理代码本身可能分配，因此可能触发 GC
  4. 若 GC 在展开中移动对象，展开器持有的异常对象引用必须被更新

// 反模式：用异常做正常控制流
try {
    for (int i = 0; ; i++) { if (i >= n) throw Done(); process(v[i]); }
} catch (Done&) { }

// 正确：用条件判断
for (int i = 0; i < n; i++) process(v[i]);

# 测量异常开销：对比正常路径与异常路径
perf stat -e cycles,instructions ./bench_normal
perf stat -e cycles,instructions ./bench_throw_catch
# 观察 .eh_frame 的体积占比
size -A ./app | grep -E "eh_frame|except_table"

// 陷阱：析构函数抛出会直接终止程序
struct Bad {
    ~Bad() { throw std::runtime_error("boom"); }   // 隐式 noexcept，调用 terminate
};
// 正确：析构不抛，或显式声明 noexcept(false) 并承担风险

// 陷阱：C 回调中抛出的异常无法穿越 C 帧
extern "C" void callback() {
    try { may_throw(); }        // 必须在 C 边界内捕获
    catch (...) { /* 转成错误码或记录 */ }
}

# 验证展开信息是否完整
readelf --debug-dump=frames ./app | grep -c "FDE"    # 统计 FDE 数量
# 用 _Unwind_Backtrace 自测展开能否走通