非本地跳转：概念和应用

herberteuler

我在寒假看 UNIX 源代码时领悟了进程管理部分，顺便也将其他的知识联系起来了，总结了一下写了一篇文章。只是我第一次尝试介绍大系统的一部分，难免说得不清楚。欢迎提出建议。

对于计算机来说，程序只不过是一连串的二进制数据。逻辑上，程序是这样被执行的：首先，计算机把程序的内容读取到内存中，并分为三个段：文本段、数据段和堆栈段。文本段包含了程序中的实际指令，程序计数器 pc 将被初始化为这个段中的某个地址。数据段包含程序中静态的和全局的变量。堆栈段用于保存程序运行时的信息，堆栈指针 sp 被初始化为栈底。然后，计算机把 pc 指向的地址中的指令读到 CPU 的寄存器中，执行它，并将 pc 的值作适当的改变使它指向下一条指令。这个过程被循环直到程序所有的指令全部被执行。特别地，我们关心函数（或者过程）调用时发生的事情。

当一个函数被调用时，我们会这样做：首先，将函数需要的参数压入到堆栈中。压入的顺序并不重要，但调用者和被调用者要有一致的约定。然后，压入被调用的函数完成后将要返回的地址。每次压入的过程都会伴随 sp 的值的改变。最后，将 pc 作适当改变来使它指向被调用函数的第一条指令。这样，CPU 就将执行被调用的函数。这时堆栈中可能还会被压入新的数据，它们是被调用函数中的非静态变量（我称为本地变量）。执行完成后，我们先把函数准备返回的结果放入 CPU 的一个寄存器中，然后从堆栈中取出所有的本地变量，并将这时的栈顶数据（它是函数的返回地址）写入 pc，再取出所有因为调用这个函数而压入到堆栈中的数据。这样，执行就可以从调用函数之前的地方继续。值得说明的是，有时除了参数和返回地址，一些寄存器的值也要被压入堆栈保存起来以便恢复。

然而，我们可以修改上面的过程。当调用一个函数时，我们把要返回的地址和堆栈指针的当前值记录下来，并在将来的某个时刻用这些保存的值修改 pc 和 sp。这样，就可以实现所谓的"非本地跳转"。ISO C 中提供了实现这些操作的函数，它们是 setjmp 和 longjmp；任何一本 C 的参考手册都解释了这两个函数。非本地跳转通常用来实现错误的恢复。介绍这个内容的材料有很多，这里就不赘述了。我们要看看这个特性的其他两个应用，而且可能会有些变形。前一个应用是操作系统中的，后一个则是 C++ 和 Java 对非本地跳转的包装（这继续了非本地跳转的初衷：错误恢复）。

1. 创建新进程 - fork

在这里，我们先来了解一下进程调度；之后我们将会知道 fork 这个令人迷惑的系统调用最初是如何实现的。

在 UNIX 中，进程被定义为程序的可执行映像。在某一时刻，一台计算机上可以有许多进程在运行，这些进程共享由操作系统管理的资源。对于每个进程来说，它都好像在一台计算机上运行，因为操作系统对它隐藏了不必要的细节。这些隐藏的一部分是通过分页来实现的。通常计算机都具有地址转换机制，可以将寄存器中的地址（称为虚地址）映射为实际的地址（称为物理地址）。在不同的环境下，同一个虚地址可以映射为不同的物理地址。虚地址是连续的，比如 0 ~ 4GB（对 Linux 来说），而与连续的一段虚地址对应的物理地址却不一定是连续的。我们把所有虚地址的集合称为虚地址空间，把所有物理地址的集合称为物理地址空间。虚地址空间可以比物理地址空间大。可以把虚地址空间等分成许多段，每一段称为一页。进程访问的每一个地址实际上都是虚地址空间中的一个地址，然后计算机将会把这个虚地址转换为物理地址。通过这种机制，对于进程来说，地址就好像是从 0 开始连续编址的，从而造成了计算机上只有它本身的假象。

我们以早期的 DEC PDP11/40 系统为例，在这个系统上运行的是 UNIX 的第 6 版内核。PDP11/40 的内存大小通常是 256KB；它的 CPU 支持两种状态：内核态和用户态，并且堆栈指针 sp 在这两种状态下可以具有不同的值。PDP11/40 中虚地址空间为 0 ~ 64KB-1，被分为 8 页（即 0 ~ 8KB-1，8KB ~ 16KB-1，......，56KB ~ 64KB-1），并且内核态和用户态下同一页对应于不同的物理地址。在内核态下，第 8 页被用于保存设备的寄存器地址，每个设备的每个寄存器，甚至 CPU 里的寄存器都可以用这些地址访问到。这样，内核态下实际上只有 7 页可用，但却可以利用一页的内存访问所有的设备。在这些寄存器中，有 32 个寄存器用来保存内存的分页信息。它们被分成两组，每组 16 个，分别用来保存内核态和用户态的分页信息。每组的 16 个又被分成 8 个小组，每小组 2 个。其中一个用来保存与某一页首地址对应的物理地址，另一个保存了这一页的其他信息（这里并不重要）。

一个进程的文本段具有最低的虚地址，数据段紧随其后，而堆栈段具有最高的虚地址（为了方便，我们省略了 bss 段）。同时，可执行文件中包含了文本段、数据段的大小信息。创建一个进程时，系统首先读取这些信息，然后根据它们计算与这个进程对应的分页信息，得到每个段开始的虚地址。同时，内核保存了一个进程虚地址 0 对应的物理地址 a0。这样，一旦将一个进程的 a0 与它每个段（文本段、数据段和堆栈段）起始地址相加的结果放入用户态的保存分页信息的寄存器并适当设置 pc 和用户态下的 sp 的值，CPU通过 pc 和 ps 访问的就是这个进程地址空间内的数据，从而使这个进程成为当前活动的进程。

为了理解 UNIX v6 内核是如何调度的，先来分析一下下面三个重要的函数，它们构成了进程创建和调度的关键。

1. _savu:
   
2.         bis     $340,PS
   
3.         mov     (sp)+,r1
   
4.         mov     (sp),r0
   
5.         mov     sp,(r0)+
   
6.         mov     r5,(r0)+
   
7.         bic     $340,PS
   
8.         jmp     (r1)
   
9. 
   
10. _aretu:
    
11.         bis     $340,PS
    
12.         mov     (sp)+,r1
    
13.         mov     (sp),r0
    
14.         br      1f
    
15. 
    
16. _retu:
    
17.         bis     $340,PS
    
18.         mov     (sp)+,r1
    
19.         mov     (sp),KISA6
    
20.         mov     $_u,r0
    
21. 1:
    
22.         mov     (r0)+,sp
    
23.         mov     (r0)+,r5
    
24.         bic     $340,PS
    
25.         jmp     (r1)

复制代码

这三个函数都是用汇编语言完成的，savu 用来将 r5 和 sp 这两个寄存器的值保存到其参数指定的连续内存中；aretu 和 retu 用来恢复 r5 和 sp 的值。aretu 使用它的参数指定的地址中的内容。而 retu 使用它的参数修改 KISA6，这会使内核态下第 7 页（6+1=7）的起始地址发生变化，从而使与第 7 页对应的物理内存发生变化。u 是操作系统保存进程信息的结构，它的前两个字保存了 r5 和 sp。在这里，_u 是一个常量（140000，或 48KB）。对于每个进程来说，u 这个结构总是位于内核态下的第 7 页。这样，retu 就可以恢复每个进程的 r5 和 sp。读者可能会联想到，在一些情况下，调用 savu 时的参数就是 u 的地址(140000)。

下面就来看看 swtch 这个调度器是如何工作的。我们列出它的代码但不做全部解释：

1. /*
   
2. * This routine is called to reschedule the CPU.
   
3. * if the calling process is not in RUN state,
   
4. * arrangements for it to restart must have
   
5. * been made elsewhere, usually by calling via sleep.
   
6. */
   
7. swtch()
   
8. {
   
9.         static struct proc *p;
   
10.         register i, n;
    
11.         register struct proc *rp;
    
12. 
    
13.         if(p == NULL)
    
14.                 p = &proc[0];
    
15.         /*
    
16.          * Remember stack of caller
    
17.          */
    
18.         savu(u.u_rsav);
    
19.         /*
    
20.          * Switch to scheduler's stack
    
21.          */
    
22.         retu(proc[0].p_addr);
    
23. 
    
24. loop:
    
25.         runrun = 0;
    
26.         rp = p;
    
27.         p = NULL;
    
28.         n = 128;
    
29.         /*
    
30.          * Search for highest-priority runnable process
    
31.          */
    
32.         i = NPROC;
    
33.         do {
    
34.                 rp++;
    
35.                 if(rp >= &proc[NPROC])
    
36.                         rp = &proc[0];
    
37.                 if(rp->p_stat==SRUN && (rp->p_flag&SLOAD)!=0) {
    
38.                         if(rp->p_pri < n) {
    
39.                                 p = rp;
    
40.                                 n = rp->p_pri;
    
41.                         }
    
42.                 }
    
43.         } while(--i);
    
44.         /*
    
45.          * If no process is runnable, idle.
    
46.          */
    
47.         if(p == NULL) {
    
48.                 p = rp;
    
49.                 idle();
    
50.                 goto loop;
    
51.         }
    
52.         rp = p;
    
53.         curpri = n;
    
54.         /* Switch to stack of the new process and set up
    
55.          * his segmentation registers.
    
56.          */
    
57.         retu(rp->p_addr);
    
58.         sureg();
    
59.         /*
    
60.          * If the new process paused because it was
    
61.          * swapped out, set the stack level to the last call
    
62.          * to savu(u_ssav).  This means that the return
    
63.          * which is executed immediately after the call to aretu
    
64.          * actually returns from the last routine which did
    
65.          * the savu.
    
66.          *
    
67.          * You are not expected to understand this.
    
68.          */
    
69.         if(rp->p_flag&SSWAP) {
    
70.                 rp->p_flag =& ~SSWAP;
    
71.                 aretu(u.u_ssav);
    
72.         }
    
73.         /* The value returned here has many subtle implications.
    
74.          * See the newproc comments.
    
75.          */
    
76.         return(1);
    
77. }

复制代码

u_rsav 正是 u 的前两个字。我们看到，swtch 首先保存了调用它的进程的 r5 和 sp（以便将来恢复），然后恢复了 0 号进程（proc[0]）的 r5 和 sp（proc[0].p_addr 就是 proc[0] 的 u 的起始地址）。下面的工作是找到另一个进程，它将被转为活动进程。找到这个进程之后，就可以用 retu 来恢复它的 r5 和 sp 了。通过调用 sureg，swtch 设置了将成为活动进程的进程的用户态页面地址寄存器，这样当 CPU 回到用户态时就可以执行这个进程的代码了。

在继续之前，让我们回顾一下 swtch 做的工作：除了找到需要的进程之外，swtch 首先保存了一个进程的 sp（我们不谈 r5 了）；而找到一个进程之后，swtch 又恢复了它的 sp。这就是实现 fork 的关键。在这个版本的内核中，fork 是这样写的：

1. fork()
   
2. {
   
3.         register struct proc *p1, *p2;
   
4. 
   
5.         p1 = u.u_procp;
   
6.         for(p2 = &proc[0]; p2 < &proc[NPROC]; p2++)
   
7.                 if(p2->p_stat == NULL)
   
8.                        goto found;
   
9.         u.u_error = EAGAIN;
   
10.         goto out;
    
11. 
    
12. found:
    
13.         if(newproc()) {
    
14.                 u.u_ar0[R0] = p1->p_pid;
    
15.                 u.u_cstime[0] = 0;
    
16.                 u.u_cstime[1] = 0;
    
17.                 u.u_stime = 0;
    
18.                 u.u_cutime[0] = 0;
    
19.                 u.u_cutime[1] = 0;
    
20.                 u.u_utime = 0;
    
21.                 return;
    
22.         }
    
23.         u.u_ar0[R0] = p2->p_pid;
    
24. 
    
25. out:
    
26.         u.u_ar0[R7] =+ 2;
    
27. }

复制代码

fork 首先在进程数组 proc 里寻找“空槽”以判断是否可以创建，然后便调用 newproc 来完成创建工作。下面是 newproc 的代码：

1. /*
   
2. * Create a new process-- the internal version of
   
3. * sys fork.
   
4. * It returns 1 in the new process.
   
5. * How this happens is rather hard to understand.
   
6. * The essential fact is that the new process is created
   
7. * in such a way that appears to have started executing
   
8. * in the same call to newproc as the parent;
   
9. * but in fact the code that runs is that of swtch.
   
10. * The subtle implication of the returned value of swtch
    
11. * (see above) is that this is the value that newproc's
    
12. * caller in the new process sees.
    
13. */
    
14. newproc()
    
15. {
    
16.         int a1, a2;
    
17.         struct proc *p, *up;
    
18.         register struct proc *rpp;
    
19.         register *rip, n;
    
20. 
    
21.         p = NULL;
    
22.         /*
    
23.          * First, just locate a slot for a process
    
24.          * and copy the useful info from this process into it.
    
25.          * The panic "cannot happen" because fork has already
    
26.          * checked for the existence of a slot.
    
27.          */
    
28. retry:
    
29.         mpid++;
    
30.         if(mpid < 0) {
    
31.                 mpid = 0;
    
32.                 goto retry;
    
33.         }
    
34.         for(rpp = &proc[0]; rpp < &proc[NPROC]; rpp++) {
    
35.                 if(rpp->p_stat == NULL && p==NULL)
    
36.                         p = rpp;
    
37.                 if (rpp->p_pid==mpid)
    
38.                         goto retry;
    
39.         }
    
40.         if ((rpp = p)==NULL)
    
41.                  panic("no procs");
    
42. 
    
43.         /*
    
44.          * make proc entry for new proc
    
45.          */
    
46. 
    
47.         rip = u.u_procp;
    
48.         up = rip;
    
49.         rpp->p_stat = SRUN;
    
50.         rpp->p_flag = SLOAD;
    
51.         rpp->p_uid = rip->p_uid;
    
52.         rpp->p_ttyp = rip->p_ttyp;
    
53.         rpp->p_nice = rip->p_nice;
    
54.         rpp->p_textp = rip->p_textp;
    
55.         rpp->p_pid = mpid;
    
56.         rpp->p_ppid = rip->p_pid;
    
57.         rpp->p_time = 0;
    
58. 
    
59.         /*
    
60.          * make duplicate entries
    
61.          * where needed
    
62.          */
    
63. 
    
64.         for(rip = &u.u_ofile[0]; rip < &u.u_ofile[NOFILE];)
    
65.                 if((rpp = *rip++) != NULL)
    
66.                         rpp->f_count++;
    
67.         if((rpp=up->p_textp) != NULL) {
    
68.                 rpp->x_count++;
    
69.                 rpp->x_ccount++;
    
70.         }
    
71.         u.u_cdir->i_count++;
    
72.         /*
    
73.          * Partially simulate the environment
    
74.          * of the new process so that when it is actually
    
75.          * created (by copying) it will look right.
    
76.          */
    
77.         savu(u.u_rsav);
    
78.         rpp = p;
    
79.         u.u_procp = rpp;
    
80.         rip = up;
    
81.         n = rip->p_size;
    
82.         a1 = rip->p_addr;
    
83.         rpp->p_size = n;
    
84.         a2 = malloc(coremap, n);
    
85.         /*
    
86.          * If there is not enough core for the
    
87.          * new process, swap out the current process to generate the
    
88.          * copy.
    
89.          */
    
90.         if(a2 == NULL) {
    
91.                 rip->p_stat = SIDL;
    
92.                 rpp->p_addr = a1;
    
93.                 savu(u.u_ssav);
    
94.                 xswap(rpp, 0, 0);
    
95.                 rpp->p_flag =| SSWAP;
    
96.                 rip->p_stat = SRUN;
    
97.         } else {
    
98.         /*
    
99.          * There is core, so just copy.
    
100.          */
     
101.                 rpp->p_addr = a2;
     
102.                 while(n--)
     
103.                        copyseg(a1++, a2++);
     
104.         }
     
105.         u.u_procp = rip;
     
106.         return(0);
     
107. }

复制代码

我们看到，newproc 所作的大部分工作是初始化 proc 这个数组里的某一项，这是初始化进程的工作。在所有的初始化完成之后，它便调用 savu(u.u_rsav) 将 sp 保存起来了。接下来，newproc 返回 0－－这是父进程得到的值。同时，系统和父进程都没有对子进程做任何操作，子进程被搁置了。当 swtch 准备使子进程成为活动进程时，就会先恢复先前由 newproc 保存起来的堆栈指针 sp，当时的栈顶是调用 newproc 后应该返回的地址。完成必需的操作之后，swtch 将返回到那里，不过返回的是 1－－这就是子进程得到的值。

虽然这个 fork 的行为和我们知道的还不一样，但原理是一样的；非本地跳转在这里起到了关键作用。

2. C++ 的异常处理机制

作为面向应用的高级语言，C++ 在 C 的基础上作了许多扩充，最主要的是面向对象的机制。为了完善这个机制，就需要加入新的异常处理方法。在 C 中，一部分处理是通过调用 setjmp 和 longjmp 用非本地跳转来实现的。C++ (和 Java) 都包装了这个方法，使用 try、throw 和 catch 来完成类似的功能。实现这个功能有许多方法，当然可以基于 setjmp 和 longjmp。这里，我们就用 GCC 中的 C++ 编译器 G++ 的实现来作为例子。不过需要补充的是，我不会 C++，对于程序执行的例外情况并不是很清楚，所以我只描述了程序正常执行时的过程。欢迎读者补充。此外，由于篇幅限制我只会介绍与非本地跳转有关的内容，读者还可能需要查看 gcc 的源代码和最后的参考资料来获得对 C++ 中异常处理的完整认识。

在 C++ 里，异常的抛出和捕获是需要异常处理系统的支持的。作为“GNU 编译器集合”的 GCC 为了简化开发，实现了这个系统。这些代码是通用的，gnat、g++ 都调用了这个系统中的函数。要阅读它们，可以下载 GCC 的源代码，然后查看 gcc 子目录下以 unwind 开头的文件。

我们从下面这段简单的 C++ 程序开始：

1. namespace Error {
   
2.         struct Exception1 { };
   
3.         struct Exception2 { };
   
4. }
   
5. 
   
6. void f(int n)
   
7. {
   
8.         if (n >= 0)
   
9.                 throw Error::Exception1();
   
10.         else
    
11.                 throw Error::Exception2();
    
12. }
    
13. 
    
14. int main(void)
    
15. {
    
16.         try {
    
17.                 f(87);
    
18.         } catch (Error::Exception1 e) {
    
19.         } catch (Error::Exception2 e) {
    
20.         }
    
21.         return 0;
    
22. }

复制代码

这段程序没有什么功能，但 g++ 编译产生的代码仍然很复杂。为了展示基于 setjmp 和 longjmp 的实现，我在 Windows 下用 Cygwin 编译了上面的程序。下面就是编译的结果，希望没有吓到读者。

1.         .file        "x.cpp"
   
2.         .text
   
3.         .align 2
   
4. .globl __Z1fi
   
5.         .def        __Z1fi;        .scl        2;        .type        32;        .endef
   
6. __Z1fi:
   
7.         pushl        %ebp
   
8.         movl        %esp, %ebp
   
9.         subl        $24, %esp
   
10.         cmpl        $0, 8(%ebp)
    
11.         js        L2
    
12.         movl        $1, (%esp)
    
13.         call        ___cxa_allocate_exception
    
14. L3:
    
15.         movl        $0, 8(%esp)
    
16.         movl        $__ZTIN5Error10Exception1E, 4(%esp)
    
17.         movl        %eax, (%esp)
    
18.         call        ___cxa_throw
    
19. L2:
    
20.         movl        $1, (%esp)
    
21.         call        ___cxa_allocate_exception
    
22. L6:
    
23.         movl        $0, 8(%esp)
    
24.         movl        $__ZTIN5Error10Exception2E, 4(%esp)
    
25.         movl        %eax, (%esp)
    
26.         call        ___cxa_throw
    
27. L1:
    
28.         .def        ___main;        .scl        2;        .type        32;        .endef
    
29.         .def        __Unwind_SjLj_Resume;        .scl        2;        .type        32;        .endef
    
30.         .def        ___gxx_personality_sj0;        .scl        2;        .type        32;        .endef
    
31.         .def        __Unwind_SjLj_Register;        .scl        2;        .type        32;        .endef
    
32.         .def        __Unwind_SjLj_Unregister;        .scl        2;        .type        32;        .endef
    
33.         .align 2
    
34. .globl _main
    
35.         .def        _main;        .scl        2;        .type        32;        .endef
    
36. _main:
    
37.         pushl        %ebp
    
38.         movl        %esp, %ebp
    
39.         pushl        %edi
    
40.         pushl        %esi
    
41.         pushl        %ebx
    
42.         subl        $92, %esp
    
43.         andl        $-16, %esp
    
44.         movl        $0, %eax
    
45.         movl        %eax, -68(%ebp)
    
46.         movl        -68(%ebp), %eax
    
47.         call        __alloca
    
48.         movl        $___gxx_personality_sj0, -36(%ebp)
    
49.         movl        $LLSDA5, -32(%ebp)
    
50.         leal        -28(%ebp), %eax
    
51.         leal        -12(%ebp), %edx
    
52.         movl        %edx, (%eax)
    
53.         movl        $L17, %edx
    
54.         movl        %edx, 4(%eax)
    
55.         movl        %esp, 8(%eax)
    
56.         leal        -60(%ebp), %eax
    
57.         movl        %eax, (%esp)
    
58.         call        __Unwind_SjLj_Register
    
59.         call        ___main
    
60.         movl        $87, (%esp)
    
61.         movl        $1, -56(%ebp)
    
62.         call        __Z1fi
    
63.         jmp        L9
    
64. L17:
    
65.         leal        12(%ebp), %ebp
    
66.         movl        -52(%ebp), %eax
    
67.         movl        %eax, -72(%ebp)
    
68.         movl        -48(%ebp), %edx
    
69.         movl        %edx, -76(%ebp)
    
70.         cmpl        $2, -76(%ebp)
    
71.         je        L10
    
72.         cmpl        $1, -76(%ebp)
    
73.         je        L13
    
74.         movl        -72(%ebp), %eax
    
75.         movl        %eax, (%esp)
    
76.         movl        $-1, -56(%ebp)
    
77.         call        __Unwind_SjLj_Resume
    
78. L10:
    
79.         movl        -72(%ebp), %edx
    
80.         movl        %edx, (%esp)
    
81.         call        ___cxa_begin_catch
    
82. L11:
    
83.         call        ___cxa_end_catch
    
84.         jmp        L9
    
85. L13:
    
86.         movl        -72(%ebp), %eax
    
87.         movl        %eax, (%esp)
    
88.         call        ___cxa_begin_catch
    
89. L14:
    
90.         call        ___cxa_end_catch
    
91. L9:
    
92.         movl        $0, -64(%ebp)
    
93. L8:
    
94.         leal        -60(%ebp), %eax
    
95.         movl        %eax, (%esp)
    
96.         call        __Unwind_SjLj_Unregister
    
97.         movl        -64(%ebp), %eax
    
98.         leal        -12(%ebp), %esp
    
99.         popl        %ebx
    
100.         popl        %esi
     
101.         popl        %edi
     
102.         popl        %ebp
     
103.         ret
     
104.         .section        .gcc_except_table,""
     
105.         .align 4
     
106. LLSDA5:
     
107.         .byte        0xff
     
108.         .byte        0x0
     
109.         .uleb128 LLSDATT5-LLSDATTD5
     
110. LLSDATTD5:
     
111.         .byte        0x1
     
112.         .uleb128 LLSDACSE5-LLSDACSB5
     
113. LLSDACSB5:
     
114.         .uleb128 0x0
     
115.         .uleb128 0x3
     
116. LLSDACSE5:
     
117.         .byte        0x1
     
118.         .byte        0x0
     
119.         .byte        0x2
     
120.         .byte        0x7d
     
121.         .align 4
     
122.         .long        __ZTIN5Error10Exception1E
     
123.         .long        __ZTIN5Error10Exception2E
     
124. LLSDATT5:
     
125.         .text
     
126. .globl __ZTIN5Error10Exception1E
     
127.         .section        .rdata$_ZTIN5Error10Exception1E,""
     
128.         .linkonce same_size
     
129.         .align 4
     
130. __ZTIN5Error10Exception1E:
     
131.         .long        __ZTVN10__cxxabiv117__class_type_infoE+8
     
132.         .long        __ZTSN5Error10Exception1E
     
133. .globl __ZTIN5Error10Exception2E
     
134.         .section        .rdata$_ZTIN5Error10Exception2E,""
     
135.         .linkonce same_size
     
136.         .align 4
     
137. __ZTIN5Error10Exception2E:
     
138.         .long        __ZTVN10__cxxabiv117__class_type_infoE+8
     
139.         .long        __ZTSN5Error10Exception2E
     
140. .globl __ZTSN5Error10Exception2E
     
141.         .section        .rdata$_ZTSN5Error10Exception2E,""
     
142.         .linkonce same_size
     
143. __ZTSN5Error10Exception2E:
     
144.         .ascii "N5Error10Exception2E\0"
     
145. .globl __ZTSN5Error10Exception1E
     
146.         .section        .rdata$_ZTSN5Error10Exception1E,""
     
147.         .linkonce same_size
     
148. __ZTSN5Error10Exception1E:
     
149.         .ascii "N5Error10Exception1E\0"
     
150.         .def        ___cxa_end_catch;        .scl        3;        .type        32;        .endef
     
151.         .def        ___cxa_begin_catch;        .scl        3;        .type        32;        .endef
     
152.         .def        ___cxa_throw;        .scl        3;        .type        32;        .endef
     
153.         .def        ___cxa_allocate_exception;        .scl        3;        .type        32;        .endef

复制代码

首先要说明的是，由于 C++ 的名字破坏机制，大多数名字都被修改了。我们的 f 被改成了_Z1fi，Exception1 被改成了 _ZTIN5Error10Exception1E。

注意到函数 main (_main) 在编译后调用了两个函数：_Unwind_SjLj_Register 和 _Unwind_SjLj_Unregister。这两个函数属于 gcc 的基于 setjmp 和 longjmp 的异常处理系统，可以在 gcc 源代码的 gcc/unwind-sjlj.c 里找到。我们只列出 _Unwind_SjLj_Register 的代码：

1. void
   
2. _Unwind_SjLj_Register (struct SjLj_Function_Context *fc)
   
3. {
   
4. #if __GTHREADS
   
5.   if (use_fc_key < 0)
   
6.     fc_key_init_once ();
   
7. 
   
8.   if (use_fc_key)
   
9.     {
   
10.       fc->prev = __gthread_getspecific (fc_key);
    
11.       __gthread_setspecific (fc_key, fc);
    
12.     }
    
13.   else
    
14. #endif
    
15.     {
    
16.       fc->prev = fc_static;
    
17.       fc_static = fc;
    
18.     }
    
19. }

复制代码

除去宏定义中的代码，函数 _Unwind_Register 的功能很明显：fc_static 是一个静态的变量，它保存了进程执行时的堆栈帧的上下文信息。这是一个单链表，每当调用一个 C++ 函数时，都会调用 _Unwind_SjLj_Register 向这个链表中添加一项。调用完成准备从函数返回时，就调用 _Unwind_SjLj_Unregister 除去链表中的一项。这些信息将在尝试捕捉异常时有用。

fc_static 是一个指向 SjLj_Function_Context 结构的指针，而 SjLj_Function_Context 结构的定义如下：

1. struct SjLj_Function_Context
   
2. {
   
3.   /* This is the chain through all registered contexts.  It is
   
4.      filled in by _Unwind_SjLj_Register.  */
   
5.   struct SjLj_Function_Context *prev;
   
6. 
   
7.   /* This is assigned in by the target function before every call
   
8.      to the index of the call site in the lsda.  It is assigned by
   
9.      the personality routine to the landing pad index.  */
   
10.   int call_site;
    
11. 
    
12.   /* This is how data is returned from the personality routine to
    
13.      the target function's handler.  */
    
14.   _Unwind_Word data[4];
    
15. 
    
16.   /* These are filled in once by the target function before any
    
17.      exceptions are expected to be handled.  */
    
18.   _Unwind_Personality_Fn personality;
    
19. 
    
20. #ifdef DONT_USE_BUILTIN_SETJMP
    
21.   /* We don't know what sort of alignment requirements the system
    
22.      jmp_buf has.  We over estimated in except.c, and now we have
    
23.      to match that here just in case the system *didn't* have more
    
24.      restrictive requirements.  */
    
25.   jmp_buf jbuf __attribute__((aligned));
    
26. #else
    
27.   void *jbuf[];
    
28. #endif
    
29. };

复制代码

这里我们关心的只有 prev 和 jbuf 这两个成员。prev 指向链表的前一个元素，jbuf 保存了与 ISO C 中的 jmp_buf 相同的内容。

仔细研究抛出异常的动作就可以知道 gcc 的异常处理系统是如何工作的。注意上面的 f 的汇编代码（_Z1fi），它先调用 __cxa_allocate_exception 生成了一个异常对象，然后初始化这个对象（这里是 _ZTIN5Error10Exception1E，如果对象是一个类则会调用它的初始化方法），最后调用 __cxa_throw。

__cxa_throw 的代码位于 libstdc++-v3/libsupc++/eh_throw.cc：

1. extern "C" void
   
2. __cxa_throw (void *obj, std::type_info *tinfo, void (*dest) (void *))
   
3. {
   
4.   __cxa_exception *header = __get_exception_header_from_obj (obj);
   
5.   header->exceptionType = tinfo;
   
6.   header->exceptionDestructor = dest;
   
7.   header->unexpectedHandler = __unexpected_handler;
   
8.   header->terminateHandler = __terminate_handler;
   
9.   header->unwindHeader.exception_class = __gxx_exception_class;
   
10.   header->unwindHeader.exception_cleanup = __gxx_exception_cleanup;
    
11. 
    
12.   __cxa_eh_globals *globals = __cxa_get_globals ();
    
13.   globals->uncaughtExceptions += 1;
    
14. 
    
15. #ifdef _GLIBCXX_SJLJ_EXCEPTIONS
    
16.   _Unwind_SjLj_RaiseException (&header->unwindHeader);
    
17. #else
    
18.   _Unwind_RaiseException (&header->unwindHeader);
    
19. #endif
    
20. 
    
21.   // Some sort of unwinding error.  Note that terminate is a handler.
    
22.   __cxa_begin_catch (&header->unwindHeader);
    
23.   std::terminate ();
    
24. }

复制代码

可以看到，__cxa_throw 先为异常对象中的某些项赋了值使它可以使用，然后就调用 _Unwind_SjLj_RaiseException 或 _Unwind_RaiseException 来抛出和捕获一个异常。如果执行正常，这两个函数都不返回，直接执行源程序中与 catch 对应的代码。_Uwind_RaiseException 和 _Unwind_SjLj_RaiseException 实际上是一个函数，只是使用了宏定义的方式而已。_Unwind_RaiseException 在 gcc/unwind.inc 里。这里我只做简单的说明，完整的说明可以在最后的参考资料中找到。

总的来说，抛出和捕获异常分为两个阶段：

- 在查找阶段，异常处理系统会尝试找到可以处理被抛出异常的处理者。利用每次调用函数时建立的链表，系统会找到每次函数调用时的堆栈。如果在那里找到了处理者，就进入第二个阶段。

- 在清理阶段，系统每次都会向回跳跃一个栈帧，并执行可能的清理工作。当跳跃到包含处理者的栈帧时，系统就恢复寄存器的状态，控制就跳回到由用户写的处理代码了。

从 _Unwind_RaiseException 的代码中我们可以看到 gcc 的实现：

1. _Unwind_Reason_Code
   
2. _Unwind_RaiseException(struct _Unwind_Exception *exc)
   
3. {
   
4.   struct _Unwind_Context this_context, cur_context;
   
5.   _Unwind_Reason_Code code;
   
6. 
   
7.   /* Set up this_context to describe the current stack frame.  */
   
8.   uw_init_context (&this_context);
   
9.   cur_context = this_context;
   
10. 
    
11.   /* Phase 1: Search.  Unwind the stack, calling the personality routine
    
12.      with the _UA_SEARCH_PHASE flag set.  Do not modify the stack yet.  */
    
13.   while (1)
    
14.     {
    
15.       _Unwind_FrameState fs;
    
16. 
    
17.       /* Set up fs to describe the FDE for the caller of cur_context.  The
    
18.          first time through the loop, that means __cxa_throw.  */
    
19.       code = uw_frame_state_for (&cur_context, &fs);
    
20. 
    
21.       if (code == _URC_END_OF_STACK)
    
22.         /* Hit end of stack with no handler found.  */
    
23.         return _URC_END_OF_STACK;
    
24. 
    
25.       if (code != _URC_NO_REASON)
    
26.         /* Some error encountered.  Ususally the unwinder doesn't
    
27.            diagnose these and merely crashes.  */
    
28.         return _URC_FATAL_PHASE1_ERROR;
    
29. 
    
30.       /* Unwind successful.  Run the personality routine, if any.  */
    
31.       if (fs.personality)
    
32.         {
    
33.           code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
    
34.                                     exc, &cur_context);
    
35.           if (code == _URC_HANDLER_FOUND)
    
36.             break;
    
37.           else if (code != _URC_CONTINUE_UNWIND)
    
38.             return _URC_FATAL_PHASE1_ERROR;
    
39.         }
    
40.        
    
41.       /* Update cur_context to describe the same frame as fs.  */
    
42.       uw_update_context (&cur_context, &fs);
    
43.     }
    
44. 
    
45.   /* Indicate to _Unwind_Resume and associated subroutines that this
    
46.      is not a forced unwind.  Further, note where we found a handler.  */
    
47.   exc->private_1 = 0;
    
48.   exc->private_2 = uw_identify_context (&cur_context);
    
49. 
    
50.   cur_context = this_context;
    
51.   code = _Unwind_RaiseException_Phase2 (exc, &cur_context);
    
52.   if (code != _URC_INSTALL_CONTEXT)
    
53.     return code;
    
54. 
    
55.   uw_install_context (&this_context, &cur_context);
    
56. }

复制代码

uw_install_context 简单地返回当前的上下文信息 (fc_static)。对 personality 函数的调用则会查找处理者。最后， uw_update_context 使栈帧向上跳跃一次。如果查找成功，_Unwind_RaiseException_Phase2 就会返回 _URC_INSTALL_CONTEXT，而调用 uw_install_context 就会跳跃到用户写的异常处理代码：

1. #define uw_install_context(CURRENT, TARGET)           \
   
2. do                                                    \
   
3.   {                                                   \
   
4.     _Unwind_SjLj_SetContext ((TARGET)->fc);           \
   
5.     longjmp ((TARGET)->fc->jbuf, 1);                  \
   
6.   }                                                   \
   
7. while (0)

复制代码

现在回到我们最初的程序编译出来的汇编代码。一旦捕获了一个异常，就会执行 .L17 中的代码。这里有一个明显的比较动作：

1.         movl    %edx, -76(%ebp)
   
2.         cmpl    $2, -76(%ebp)
   
3.         je      L10
   
4.         cmpl    $1, -76(%ebp)
   
5.         je      L13
   
6.         movl    -72(%ebp), %eax
   
7.         movl    %eax, (%esp)
   
8.         movl    $-1, -56(%ebp)
   
9.         call    __Unwind_SjLj_Resume

复制代码

1 和 2 是 g++ 为 Exception1 和 Exception2 产生的不同的标识，通过它，就可以对捕获到的 Exception1 类型的和 Exception2 类型的异常作出不同的处理。此外，如果没有可以处理的例程，就调用 _Unwind_SjLj_Resume，而 _Unwind_SjLj_Resume 会调用 std::terminate 来使程序异常终止。

至于正常执行的路径，汇编代码非常清楚，这里就不说明了。

我们来看看 C++ ABI for Itanium: Exception Handling 举出的 C++ 异常实现的例子，它可以加深对 g++ 产生的汇编代码的理解。下面的 try-catch 块：

1. try { foo(); }
   
2. catch (TYPE1) { ... }
   
3. catch (TYPE2) { buz(); }
   
4. bar();

复制代码

可以翻译成这样：

1. // In "Normal" area:
   
2. foo(); // Call Attributes: Landing Pad L1, Action Record A1
   
3. goto E1;
   
4. ...
   
5. E1: // End Label
   
6. bar();
   
7. 
   
8. // In "Exception" area;
   
9. L1: // Landing Pad label
   
10. [Back-end generated ompensationcode]
    
11. goto C1;
    
12. 
    
13. C1: // Cleanup label
    
14. [Front-end generated cleanup code, destructors, etc]
    
15. [corresponding to exit of try { } block]
    
16. goto S1;
    
17. 
    
18. S1: // Switch label
    
19. switch(SWITCH_VALUE_PAD_ARGUMENT)
    
20. {
    
21.     case 1: goto H1; // For TYPE1
    
22.     case 2: goto H2; // For TYPE2
    
23.     //...
    
24.     default: goto X1;
    
25. }
    
26. 
    
27. X1:
    
28. [Cleanup code corresponding to exit of scope]
    
29. [enclosing the try block]
    
30. _Unwind_Resume();
    
31. 
    
32. H1: // Handler label
    
33. [Initialize catch parameter]
    
34. __cxa_begin_catch(exception);
    
35. [User code]
    
36. goto R1;
    
37. 
    
38. H2:
    
39. [Initialize catch parameter]
    
40. __cxa_begin_catch(exception);
    
41. [User code]
    
42. buz(); // Call attributes: Landing pad L2, action record A2
    
43. goto R1;
    
44. 
    
45. R1: // Resume label:
    
46. __cxa_end_catch();
    
47. goto E1;
    
48. 
    
49. L2:
    
50. C2:
    
51. // Make sure we cleanup the current exception
    
52. __cxa_end_catch();
    
53. 
    
54. X2:
    
55. [Cleanup code corresponding to exit of scope]
    
56. [enclosing the try block]
    
57. _Unwind_Resume();

复制代码

如果读者用 -static 来编译程序并反汇编得到的可执行文件，将会发现凡是 C++ 例程都会在进入以后先调用 _Unwind_Register，并在返回之前调用 _Unwind_Unregister。这样，就保证异常处理系统可以正常工作。这也就是 C 编译器和 C++ 编译器的不同之处。为了方便应用层程序员编写程序，C++ 确实在背后做了许多工作。而异常处理这一部分，是可以用非本地跳转的方式来实现的。

上面我们看到了应用非本地跳转的两个例子。这是一个非常底层的功能：我们需要理解计算机如何执行程序才能用上这个功能，并且要使用它们必须使用汇编语言。但是，它也因此而具有强大的功能，这个功能被聪明的人利用以后成为了许多灾难的来源。大多数程序的漏洞──缓冲区溢出──也是因为返回地址被修改，这也算是非本地跳转的一个鲜明的例子吧。

参考资料

我对应用非本地跳转的理解来自 UNIX 的源代码。有一本非常不错的书，John Lions 的 Commentary on UNIX 6th Edition with Source Code，介绍了第 6 版 UNIX 内核。虽然它已经很老了，但它包含了最初的结构，后来的许多改进都没有摆脱它的影响；此外，通过阅读 UNIX v6 的源代码，一个人可以在很短的时间内对一个完整的操作系统有比较深入的理解。

关于 C++ 的异常处理，我的理解来自 C++ ABI for Itanium: Exception Handling (http://www.codesourcery.com/cxx-abi/abi-eh.html)。我不会 C++，对 C++ 的资料也不熟悉，但希望这个网址对 C++ 的爱好者有帮助。

另一本书是 Randal E. Bryant 和 David O'Hallaron 的 Computer Systems: A Programmer's Perspective。它有中文版，由龚奕利、雷迎春翻译，名为深入理解计算机系统。这本书对计算机系统做了详细和完备的介绍，值得一看。

最后，自由软件带来的开放源代码运动是最好的教室。要更深入地理解 gcc 的异常处理系统，可以看一下 gcc 源代码中 gcc 子目录里 unwind 开头的文件和 libstdc++-v3/libsupc++ 子目录下 eh 开头的文件。

kj501

呵呵，能理解到这么多已经不错了。支持原创！

yangtou

哈哈,刚开始看lions,谢谢楼主

herberteuler

Post by yangtou
哈哈,刚开始看lions,谢谢楼主

我收集了大量与 Lions 的书相关的资料，包括原书的电子版、PDP11 处理器指令的说明和 PDP11 外围设备手册，以及其他的资料，共 100 MB。本来我想把它放到 LinuxSir 的 ftp 服务器上，但是没有账号。

yangtou

我也收集了一些资料,
英文版的lions包括源码,PDP11-40 Processor Handbook,UNIX Assembler Reference Manual,PDP11 PDP11_PeripheralsHbk_1972.pdf PDP11_PeripheralsHbk_1976.pdf 1140_SystemManual.pdf等
还有一些超星上的关于pdp11体系结构和汇编的资料

刚开始看,以前没有看过多少代码,还要向herberteuler多多请教,herberteuler 能不能给个邮箱啊

nait

楼上的UNIX Assembler Reference Manual能否共享一下?
email:
nait83 (AT) 126 (DOT) com
谢谢