本文内容主要来源于?C++ exceptions under the hood，环境为 gcc/x86，原文非常长且专注于实现自己的异常机制，感兴趣可以看原文，本文只针对于原理介绍与术语讲解。
1、太长不看版总结
- 编译器会将?
throw?语句翻译成一对?libstdc++?库里的函数，包括为异常处理分配内存、调用?libstdc?来进行栈展开(stack unwinding)。 - 对于每个?
catch?语句的存在，编译器会在函数末尾加上一些特殊信息，包括当前函数可以捕获的异常表，以及清理表(cleanup table)。 - 在进行栈展开时，会调用?
libstdc++?提供的特殊函数(称为 personality routine)，会检查栈上的所有函数哪个异常可以被捕获。 - 如果异常无法被捕获，那么?
std::terminate?就会被调用。 - 如果找到了能够匹配的捕获操作，展开处理(unwinder)会再次在栈顶进行操作。
- unwinder 第二次遍历栈时，会要求 personality routine 去为当前函数执行清理操作。
- personality routine 会检查当前函数的清理表。如果有什么清理操作要执行的话，就会直接跳到当前栈帧(stack frame)，执行清理操作(cleanup code)。这会引起每个在当前作用域分配的对象的析构操作。
- 一旦 unwinder 到达了可以处理异常的栈帧时，它会跳到对应的?
catch?语句当中。 - 执行完 catch 语句后，会调用清理函数去释放掉为异常所分配的内存。
2、throw
2.1、案例分析
尝试在 C 里面用 C++ 的异常机制(即采用纯 C 的链接器来链接 C++ 的?throw?程序)，看下会有什么事情发生：
struct Exception {};
extern "C" {
void seppuku() {
throw Exception();
}
}
先正常编译 C 和 C++ 的源代码：
> g++ -c -o throw.o -O0 -ggdb throw.cpp
> gcc -c -o main.o -O0 -ggdb main.c然后在链接期间就会出现以下错误：
> gcc main.o throw.o -o app
throw.o: In function `foo()':
throw.cpp:4: undefined reference to `__cxa_allocate_exception'
throw.cpp:4: undefined reference to `__cxa_throw'
throw.o:(.rodata._ZTI9Exception[typeinfo for Exception]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
collect2: ld returned 1 exit status说明编译器暗中插入了对异常机制进行处理的函数。
2.2、__cxa_allocate_exception
该函数接受一个?size_t?类型的参数，然后为抛出的异常分配内存。
这里的内存分配到哪里是有讲究的，比如说：
- 栈上(stack) —— 异常机制需要进行栈展开，分配到栈上不合理
- 堆上(heap) —— 有时可能要抛出爆内存 OOM(out of memory) 的异常，分配到堆上也不合理
- 静态分配(static) —— 线程不安全
- 线程局部存储(local thread storage) —— 大部分实现采用这种，若 OOM，则采用特殊应急内存(一般为 static)
2.3、__cxa_throw
一旦异常被创建，该函数就会被调用。
该函数负责进行栈展开的操作，它永远不会返回(return)，要么就是跳转到对应的?catch?块去处理异常，要么就是默认地调用?std::terminate?终止程序。
该函数会准备好一大堆东西，然后把异常递交给?_Unwind_?，是一系列的 libstdc 里的函数进行真正的栈展开操作。
2.4、vtable for?cxxabiv1::class_type_info
这个明显就是 RTTI(Run-Time Type Identification) 里的一种，它是用来在运行时判断两种类型是否一致。
在这里，是用来判断一个?catch?是否能够处理(handle)一个?throw。
2.5、自定义简单实现
有了以上这些信息，我们就可以写个简单的代码来提供这些接口：
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
namespace __cxxabiv1 {
struct __class_type_info {
virtual void foo() {}
} ti;
}
#define EXCEPTION_BUFF_SIZE 255
char exception_buff[EXCEPTION_BUFF_SIZE];
extern "C" {
void* __cxa_allocate_exception(size_t thrown_size)
{
printf("alloc ex %i\n", thrown_size);
if (thrown_size > EXCEPTION_BUFF_SIZE) printf("Exception too big");
return &exception_buff;
}
void __cxa_free_exception(void *thrown_exception);
#include <unwind.h>
void __cxa_throw(
void* thrown_exception,
struct type_info *tinfo,
void (*dest)(void*))
{
printf("throw\n");
// __cxa_throw never returns
exit(0);
}
} // extern "C"
2.6、汇编查看
用汇编看下编译器所进行的暗中操作：
.LFB3:
[...]
call __cxa_allocate_exception
movl $0, 8(%esp)
movl $_ZTI9Exception, 4(%esp)
movl %eax, (%esp)
call __cxa_throw
[...]我们看到了对那两个函数的调用，但是编译器还不知道应该怎么处理异常，所以需要能够选择到对应的异常处理函数才行。
3、catch
struct Fake_Exception {};
void raise() {
throw Exception();
}
// We will analyze what happens if a try block doesn't catch an exception
void try_but_dont_catch() {
try {
raise();
} catch(Fake_Exception&) {
printf("Running try_but_dont_catch::catch(Fake_Exception)\n");
}
printf("try_but_dont_catch handled an exception and resumed execution");
}
同样采用纯 C 的链接器去链接 C++ 的?catch?程序：
> gcc main.o throw.o mycppabi.o -O0 -ggdb -o app
throw.o: In function `try_but_dont_catch()':
throw.cpp:12: undefined reference to `__cxa_begin_catch'
throw.cpp:12: undefined reference to `__cxa_end_catch'
throw.o:(.eh_frame+0x47): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status在执行 catch 块代码的时候，会先要调用?__cxa_begin_catch?函数对异常对象进行调整(计数器、放置到栈顶)，执行完后会调用?__cxa_end_catch?函数进行异常对象的销毁。
4、Unwinder
__cxa_throw?会准备好一大堆东西，然后把异常递交给?_Unwind_?，是一系列的 libstdc 里的函数进行真正的栈展开操作。
那么它是怎么找到对应的 catch 块的呢？
异常捕获需要有一定程度的反射(reflexion)的支持(即程序有能力分析它自己的代码)。
用汇编探索下实际的调用情况，为了更加直观，只保留重要的汇编代码。
先看下?raise?函数做了什么：
_Z5raisev:
call __cxa_allocate_exception
call __cxa_throw正常地对?throw?异常机制的两个函数进行了调用。
再看下?try_but_dont_catch?函数的情况：
_Z18try_but_dont_catchv:
.cfi_startproc
.cfi_personality 0,__gxx_personality_v0
.cfi_lsda 0,.LLSDA1链接器会根据 CFI(call frame information) 指令来进行函数的使用判断，CFI 指令信息通常用在栈展开中。
LSDA(language specific data area) 的信息会被 personality 函数使用，用来知悉哪个函数(块)可以处理该异常。
4.1、LSDA
LSDA 的内容包含有：
- 指向相关数据的指针 —— landing pad start pointer(记录偏移量)、types table pointer(type info 索引)
- 一个保存了调用点的列表 —— 可能会抛出异常的调用点(call sites)
- 一个操作记录(action table)的列表 —— catch 块信息、异常的规范
每个来自于 C++ 代码的程序片段都会有自己的 LSDA，它会被加到 .gcc_except_table 当中。
4.2、personality
由于在处理异常时，不同编程语言会存在不同的处理行为，所以异常处理 ABI 提供了一个机制来满足不同的 personality(性格)。
一个异常处理的 personality 会被 personality 函数所定义，比如 C++ 是?__gxx_personality_v0，它会接收异常的上下文，一个异常结构体包含有异常对象的类型和值，以及指向当前函数的异常表(exception table)的引用。
对于当前的编译单元，personality 函数会在异常的栈帧中被指明。
4.3、CFI
CFI(call frame information)实际上是汇编辅助指令(非 CPU 真实指令)，用来描述栈帧的结构。
我们需要 CFI，因为手写的汇编代码不会有编译器生成的调试信息，而且为了调试器能够遍历核心文件(core file)，或者分析 profilers 能够正确地进行栈展开操作，CFI 都是有必要的。
在异常处理当中，CFI 信息可以用来辅助找到对应的 landing pads 和进行栈展开。
CFI 指令以?.cfi_?开头。为了进行栈展开，还需要定义 CFA(Canonical Frame Address)，代表调用函数在 CALL 指令前 sp(stack pointer，栈指针)的值。我们的任务是定义数据，来使对于给定的任何指令，CFA 都能够被计算出来。
其中一种设计就是 CFI 表，会为每一条指令保存 (register, offset) 的数据对，但为了减少其大小，只保存指令当中被改变的数据。
.globl square
.type square,@function
.hidden square
square:
.cfi_startproc ; 开始 CFI 记录，.eh_frame 的入口
push rbp
.cfi_adjust_cfa_offset 8 ; 前面有入栈操作，所以更新偏移量
mov rbp, rsp
.cfi_def_cfa_register rbp ; 用寄存器来定义 CFA 的值
mov DWORD PTR [rbp-4], edi
mov eax, DWORD PTR [rbp-4]
imul eax, DWORD PTR [rbp-4]
pop rbp
.cfi_def_cfa rsp, 8 ; 用寄存器加偏移量的方式定义 CFA 的值
ret
.cfi_endproc ; 结束 CFI 记录，生成到 .eh_frame 中4.4、CIE & FDE
CFI 表可以用?objdump?导出为两张表：CIE(Common Information Entry) 和 FDE(Frame Description Entry)。
CIE 表包含所有函数的基本信息：
… CIE
Version: 1
Augmentation: "zR"
Code alignment factor: 1
Data alignment factor: -8
Return address column: 16
Augmentation data: 1b
DW_CFA_def_cfa: r7 (rsp) ofs 8
DW_CFA_offset: r16 (rip) at cfa-8FDE 表包含函数的 CFI 指令信息：
… FDE cie=…
DW_CFA_advance_loc: 1 to 0000000000000001
DW_CFA_def_cfa: r7 (rsp) ofs 16
DW_CFA_advance_loc: 3 to 0000000000000004
DW_CFA_def_cfa: r6 (rbp) ofs 16
DW_CFA_advance_loc: 11 to 000000000000000f
DW_CFA_def_cfa: r7 (rsp) ofs 84.5、try-catch 块
用汇编来看下函数 try-catch 块的行为：
[...]
call _Z5raisev ; raise 函数中调用了 __cxa_throw，正常不会返回
jmp .L8 ; 如果是正常函数，则会返回并继续执行
cmpl $1, %edx ; catch 语句对应的起始指令
je .L5 ; 检查异常是否能被处理
.LEHB1:
call _Unwind_Resume ; 不能处理则调用 栈恢复 函数，即清理操作
.LEHE1:
.L5:
call __cxa_begin_catch ; 若能处理，则开始 catch 块的执行
call __cxa_end_catch ; 中间会夹杂着 catch 块的逻辑
.L8: ; 函数的末尾
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc如果?raise?函数不能正常处理异常，那么它的下一条指令?jmp .L8?就不应该执行，而是应该在异常处理(exception handers)当中，又称之为 landing pad。
4.5.1、landing pad
The term used to define the place where an?invoke?continues after an exception is called a landing pad.
术语 landing pad 代表：在异常处理当中应该去执行(跳转到)的位置。
landing pads 会有三种：
- cleanup clause —— 调用 destructors of out-of-scope variables 或?
__attribute__((cleanup(...)))?注册的 callbacks，然后调用?_Unwind_Resume?跳转到清理操作 - catch clause —— 调用 destructors of out-of-scope variables，跳转到?
__cxa_begin_catch?调用，然后是?catch?块，最后是?__cxa_end_catch?调用 - rethrow：调用 destructors of out-of-scope variables in the catch clause，然后调用?
__cxa_end_catch，接着用?_Unwind_Resume?跳转回 cleanup phase
在 LLVM 当中，landing pads 是概念上的可选的函数入口(entry points)，参数为一个对异常结构体的引用，和一个 type info 的索引。
landing pad 会保存异常结构体的引用，并且会用异常对象对应的 type info 去选择正确?catch?块。
在?LLVM’s exception handling system?当中，会有 ‘landingpad’ 指令来指明一个代码块(basic block)是 landing pad。
;; A landing pad which can catch an integer.
%res = landingpad { i8*, i32 }
catch i8** @_ZTIi
;; A landing pad that is a cleanup.
%res = landingpad { i8*, i32 }
cleanup
;; A landing pad which can catch an integer and can only throw a double.
%res = landingpad { i8*, i32 }
catch i8** @_ZTIi
filter [1 x i8**] [@_ZTId]那么如何找到对应的 landing pad，这就要求?_Unwind_?遍历调用栈，看哪个调用具有合适的带 landing pad 的 try 块可以捕获异常。
4.6、__gcc_except_table
那么?_Unwind_?是怎么找到合适的 landing pad 的？这时候就需要类似反射的信息的辅助了。
为了知晓 landing pads 在哪里，就用到了 __gcc_except_table，在函数的末尾可以找到：
.LFE1:
.globl __gxx_personality_v0
.section .gcc_except_table,"a",@progbits
[...]
.LLSDACSE1:
.long _ZTI14Fake_Exception它会帮助我们来定位 landing pad 被保存到什么位置，实际上是找到 LSDA，然后 personality 函数会检查 LSDA 能不能处理异常。
ELF 文件里 LSDA 通常就保存在 .gcc_except_table 段当中，该段会由 personality 函数来进行解析。
如果为函数指定了?nothrow?的标识符，那么就不会生成该信息，可以减少代码大小，但当异常被抛出时，由于没有 LSDA 的信息，personality 函数不知道该怎么办，通常会调用默认的异常处理机制，所以大概率会调用?std::terminate。
5、two-phase handling
personality 函数的参数含有 action 类型，代表?_Unwind_要求执行什么样的操作，因为捕获异常分为两个阶段：lookup 和 cleanup。
Unwind 会尝试定位异常的 landing pad，而 personality 函数的返回值类型是?_Unwind_Reason_Code，如果是?_URC_HANDLER_FOUND?则代表找到了 landing pad，否则会返回?_URC_CONTINUE_UNWIND?让 Unwind 从下一个栈帧进行尝试。
如果都没找到，那么会调用默认的异常处理机制(std::terminate)。
找到了 landing pad 后，Unwind 会再次遍历栈，调用 personality 函数，采用?_UA_CLEANUP_PHASE?的 action 操作，而 personality 函数会再次检查是否能处理当前的异常。
如果无法处理，则会执行 LSDA 所指定的 cleanup 函数：会执行当前栈上所有对象的析构操作。
如果可以处理，则不会执行 cleanup 函数，会告诉 Unwind 在 landing pad 恢复执行。
为什么 lookup 的时候已经找到了可以处理异常的栈帧，但还要再遍历一次栈，因为这样 personality 函数就有机会对作用域内的对象进行析构操作，从而使得 RAII(Resource Acquisition Is Initialization) 是异常机制安全的操作。
参考
C++ exceptions under the hood：https://monkeywritescode.blogspot.com/p/c-exceptions-under-hood.html
C++ exception handling ABI：https://maskray.me/blog/2020-12-12-c++-exception-handling-abi
Itanium C++ ABI: Exception Handling：https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html
C++异常机制的实现方式和开销分析：http://baiy.cn/doc/cpp/inside_exception.htm?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
Exception Handling in LLVM：https://llvm.org/docs/ExceptionHandling.html#overview
Personality Function：https://llvm.org/docs/LangRef.html#personalityfn
‘landingpad’ Instruction：https://llvm.org/docs/LangRef.html#i-landingpad
CFI directives in assembly files：https://www.imperialviolet.org/2017/01/18/cfi.html
CFI directives：https://sourceware.org/binutils/docs/as/CFI-directives.html
Exception Handling Tables：https://itanium-cxx-abi.github.io