- A+
前言
之前在写 apue 系列的时候,曾经对系统接口的很多行为产生过好奇,当时就想研究下对应的源码,但是苦于 linux 源码过于庞杂,千头万绪不知从何开启,就一直拖了下来。
最近在查一个问题时无意间接触到了 code browser 这个在线源码查看器,它同时解决了源码包下载和环境搭建的问题,版本也帮你选好了,直接原地起飞进入源码查看:
下面是查找 glibc exit 的过程:
语法高亮、风格切换、跳转 (定义/引用) 等功能做的还是很全面的,看代码绰绰有余,简直是我等 coder 之福音。
这里感谢 Bing 同学的介绍,感兴趣读者可以在文末参考它写的关于 glibc exit 的另一篇文章,也很不错的。
glibc exit
之前写过一篇介绍 linux 进程环境的文章(《 [apue] 进程环境那些事儿》),其中提到了 glibc exit 会主动调用 atexit 注册的处理器,且有以下特性:
- LIFO,先进后出的顺序
- 注册几次调用几次
- atexit 处理器中再次调用 exit 能完成剩余处理器的调用
- atexit 处理器中再次注册的 atexit 处理器能被调用
下面带着这些问题,来看 glibc exit 的源码,以及它是如何实现上面这些特性的。
atexit 处理器结构
开门见山:
void exit (int status) { __run_exit_handlers (status, &__exit_funcs, true, true); } static struct exit_function_list initial; struct exit_function_list *__exit_funcs = &initial; uint64_t __new_exitfn_called;
exit 只调用了一个 __run_exit_handlers 接口,它需要的 atexit 处理器列表存储在 __exit_funcs 参数中,是从这里传入的。
未曾开言先转腚,来看下 __exit_funcs 的结构:
enum { ef_free, /* `ef_free' MUST be zero! */ ef_us, ef_on, ef_at, ef_cxa }; struct exit_function { /* `flavour' should be of type of the `enum' above but since we need this element in an atomic operation we have to use `long int'. */ long int flavor; union { void (*at) (void); struct { void (*fn) (int status, void *arg); void *arg; } on; struct { void (*fn) (void *arg, int status); void *arg; void *dso_handle; } cxa; } func; }; struct exit_function_list { struct exit_function_list *next; size_t idx; struct exit_function fns[32]; };
exit_function_list 作为容器有点类似 stl 中的 deque,是由 exit_function 块组成的链表,兼顾了可扩展性与遍历效率两个方面:
其中 idx 记录了实际的元素个数,块之间通过 next 指针链接。
注意第一个块是在栈上分配的 initial 对象,之后的块才是在堆上分配的。
fns 数组存储的 exit_function 记录可以包含三种不同类型的函数原型:
- void (*at) (void) : atexit 注册的函数
- void (*on) (int status, void* arg) :__on_exit 注册的函数,与 atexit 的不同之处仅在于回调时多了一个 status 参数
- void (*cxa) (void *arg, int status) :__internal_atexit 注册的函数,它又被以下接口调用:
- __cxa_atexit,在程序退出或 so 卸载时调用,主要是为编译器开放的内部接口
- __cxa_at_quick_exit,它又被 __new_quick_exit 所调用,后者和 exit 几乎一致
其中 quick_exit 调用 __run_exit_handlers 的后两个参数为 false,少清理了一些内容,以达到"快速退出"的目的。
void __new_quick_exit (int status) { /* The new quick_exit, following C++11 18.5.12, does not run object destructors. While C11 says nothing about object destructors, since it has none, the intent is to run the registered at_quick_exit handlers and then run _Exit immediately without disturbing the state of the process and threads. */ __run_exit_handlers (status, &__quick_exit_funcs, false, false); }
另外 atexit 也是通过调用 __cxa_atexit 实现的:
int atexit (void (*func) (void)) { return __cxa_atexit ((void (*) (void *)) func, NULL, __dso_handle); }
arg 参数为 NULL;so 模块句柄默认为当前模块。 所以实际上并没有类型为 ef_at 的处理器,基本全是 ef_cxa,另外
- 将 ef_free 置为整个 enum 第一个元素也是有用意的,通过 calloc 分配的内存,自动将内容清零,而对应的 flavor 恰好就是 ef_free
- ef_us (use) 表示槽位被占用,但是具体的类型有待后面设置 (ef_at/ef_on/ef_cxa),具有一些临时性,但不可或缺
处理器的注册
直接上源码:
int __internal_atexit (void (*func) (void *), void *arg, void *d, struct exit_function_list **listp) { struct exit_function *new; /* As a QoI issue we detect NULL early with an assertion instead of a SIGSEGV at program exit when the handler is run (bug 20544). */ assert (func != NULL); __libc_lock_lock (__exit_funcs_lock); new = __new_exitfn (listp); if (new == NULL) { __libc_lock_unlock (__exit_funcs_lock); return -1; } new->func.cxa.fn = (void (*) (void *, int)) func; new->func.cxa.arg = arg; new->func.cxa.dso_handle = d; new->flavor = ef_cxa; __libc_lock_unlock (__exit_funcs_lock); return 0; }
参数赋值到变量 new 的成员后,没看到插入列表的动作,怀疑是在 __new_exitfn 时直接分配的:
/* Must be called with __exit_funcs_lock held. */ struct exit_function * __new_exitfn (struct exit_function_list **listp) { struct exit_function_list *p = NULL; struct exit_function_list *l; struct exit_function *r = NULL; size_t i = 0; if (__exit_funcs_done) /* Exit code is finished processing all registered exit functions, therefore we fail this registration. */ return NULL; for (l = *listp; l != NULL; p = l, l = l->next) { for (i = l->idx; i > 0; --i) if (l->fns[i - 1].flavor != ef_free) break; if (i > 0) break; /* This block is completely unused. */ l->idx = 0; } if (l == NULL || i == sizeof (l->fns) / sizeof (l->fns[0])) { /* The last entry in a block is used. Use the first entry in the previous block if it exists. Otherwise create a new one. */ if (p == NULL) { assert (l != NULL); p = (struct exit_function_list *) calloc (1, sizeof (struct exit_function_list)); if (p != NULL) { p->next = *listp; *listp = p; } } if (p != NULL) { r = &p->fns[0]; p->idx = 1; } } else { /* There is more room in the block. */ r = &l->fns[i]; l->idx = i + 1; } /* Mark entry as used, but we don't know the flavor now. */ if (r != NULL) { r->flavor = ef_us; ++__new_exitfn_called; } return r; }
确实如此,另外这个内部接口是没有锁的,所以调用它的接口必需持有锁 (__exit_funcs_lock)。
代码不太好看,直接上图,当第一次分配时,仅有 initial 一个块,内部 32 个槽位,第一次命中最后的 else 条件,直接分配处理器 (场景 1):
前 32 个都不用额外分配内存 (场景 2):
第 33 个开始分配新的 exit_function_list,并移动 __exit_funcs 指针指向新分配的块作为列表的头 (场景 3):
结合上面的场景来理解下代码:
- 插入记录时,第一个 for 循环基本不进入,因为当前块一般有有效的记录 (for 循环的作用是寻找第一个不空闲的块,这只在 atexit 处理器被调用且在其中注册新的处理器时才有用,所以暂时放一放)
- l 一般指向当前分配的块,中间这个 if 大段落,如果记录不满,则直接分配新的元素 (else),并递增 idx,此时对应场景 1 & 2
- 如果 l 为空或记录已满,则分配新的块。此时对应场景 3,__exit_funcs 作为链表头会指向新分配的块,将 idx 设置为 1,并将第一个记录返回
- 最后设置新分配记录的 flavor 为 ef_us 表示占用
因为 atexit 没提供对应的撤销方法,所以这个 deque 在程序运行期间只会单向增长。
另外有几个小的点也需要注意,后面会用到:
- 初始时判断了 __exit_funcs_done 标志位,如果已经设立,就不允许分配新的记录了
- 设置 flavor 的同时也递增了变量 __new_exitfn_called 的值,它记录了总的处理器注册总量,因为在清理函数被调用时可能会注册新的处理器 (此时总量将超过 deque 的尺寸)
处理器的调用
直接上代码:
/* Call all functions registered with `atexit' and `on_exit', in the reverse of the order in which they were registered perform stdio cleanup, and terminate program execution with STATUS. */ void __run_exit_handlers (int status, struct exit_function_list **listp, bool run_list_atexit, bool run_dtors) { /* First, call the TLS destructors. */ if (run_dtors) __call_tls_dtors (); __libc_lock_lock (__exit_funcs_lock); /* We do it this way to handle recursive calls to exit () made by the functions registered with `atexit' and `on_exit'. We call everyone on the list and use the status value in the last exit (). */ while (true) { struct exit_function_list *cur; restart: cur = *listp; if (cur == NULL) { /* Exit processing complete. We will not allow any more atexit/on_exit registrations. */ __exit_funcs_done = true; break; } while (cur->idx > 0) { struct exit_function *const f = &cur->fns[--cur->idx]; const uint64_t new_exitfn_called = __new_exitfn_called; switch (f->flavor) { void (*cxafct) (void *arg, int status); void *arg; case ef_free: case ef_us: break; case ef_on: ... case ef_at: ... case ef_cxa: /* To avoid dlclose/exit race calling cxafct twice (BZ 22180), we must mark this function as ef_free. */ f->flavor = ef_free; cxafct = f->func.cxa.fn; arg = f->func.cxa.arg; /* Unlock the list while we call a foreign function. */ __libc_lock_unlock (__exit_funcs_lock); cxafct (arg, status); __libc_lock_lock (__exit_funcs_lock); break; } if (__glibc_unlikely (new_exitfn_called != __new_exitfn_called)) /* The last exit function, or another thread, has registered more exit functions. Start the loop over. */ goto restart; } *listp = cur->next; if (*listp != NULL) /* Don't free the last element in the chain, this is the statically allocate element. */ free (cur); } __libc_lock_unlock (__exit_funcs_lock); if (run_list_atexit) RUN_HOOK (__libc_atexit, ()); _exit (status); }
先整理下主脉络:
- __call_tls_dctors 处理线程局部存储的释放,这里不涉及主题,略过
- 主循环加锁遍历处理器 deque
- 处理 libc 的 atexit 列表,略过
- 调用 _exit 退出进程
重点就落在中间的两个 while 循环上,外层用于遍历块,内层遍历块上的记录。为突出重点,switch 内只保留了 ef_cxa 的内容,其它的类似。
- 回顾之前列表建立的过程,cur 指向的是最新分配的处理器,所以调用顺序 FILO 的问题得到了解答,特别是在遍历块内部时,也是倒序遍历的
- 在回调前解锁,回调后加锁,这样避免用户在回调中再次调用 atexit 注册处理器时发生死锁
- 每次回调之前记录当前处理器的总量 (new_exitfn_called),回调结束后将它与当前值对比,从而可以得知是否设置了新的 atexit 处理器
- 如果相同,表示没有注册新处理器,对当前结构没影响,继续遍历当前块和整个 deque
- 如果不相同,说明插入了新记录,当前指针已经失效,需要重新遍历,这里直接 goto restart 重新开始遍历
- 注意在回调前,先将处理器信息复制到栈上,同时将 flavor 设置为 ef_free,避免重启遍历时,重复遍历此记录造成死循环
- 整个块遍历结束后,移动 __exit_funcs 到下个块,同时释放当前块,如果下个块不为空的话 (当移动到 initial 时,next 为空,不释放 initial 指向的内存,因为它不是在堆上分配的)
- 当 cur 遍历到最后一个块 (initial) 的 next (NULL) 后,表明整个 deque 遍历完毕,设置 __exit_funcs_done 标志,这可以阻止 atexit 再次注册处理器
特性分析
有了上面的铺垫,再来分析其它的特性就清楚了:
- 注册几次回调几次,这是因为插入了多个记录,虽然它们的 func 字段都指向同一个地址
- 处理器中调用 exit 能完成剩余处理器的调用,原因分为两个方面:
- 处理器回调前已经解锁,因此再次调用 exit 时可以正常进入这里
- 处理器回调前已经把标志设为了 ef_free,所以再次遍历时,不会再处理当前记录,而是接着之前遍历位置继续遍历
- 最终呈现的效果是剩余的处理器被接着调用了,但是这里一定要清楚,调用 exit 的回调其实没有返回,_exit 会保证它终结在最深层的处理器那里
最后一个特性:处理器中再次注册的 atexit 处理器能被调用,这个稍微复杂一点,需要结合之前注册部分的逻辑来看,再复习一下 __new_exitfn:
/* Must be called with __exit_funcs_lock held. */ struct exit_function * __new_exitfn (struct exit_function_list **listp) { struct exit_function_list *p = NULL; struct exit_function_list *l; struct exit_function *r = NULL; size_t i = 0; if (__exit_funcs_done) /* Exit code is finished processing all registered exit functions, therefore we fail this registration. */ return NULL; for (l = *listp; l != NULL; p = l, l = l->next) { for (i = l->idx; i > 0; --i) if (l->fns[i - 1].flavor != ef_free) break; if (i > 0) break; /* This block is completely unused. */ l->idx = 0; } if (l == NULL || i == sizeof (l->fns) / sizeof (l->fns[0])) { /* The last entry in a block is used. Use the first entry in the previous block if it exists. Otherwise create a new one. */ if (p == NULL) { assert (l != NULL); p = (struct exit_function_list *) calloc (1, sizeof (struct exit_function_list)); if (p != NULL) { p->next = *listp; *listp = p; } } if (p != NULL) { r = &p->fns[0]; p->idx = 1; } } else { /* There is more room in the block. */ r = &l->fns[i]; l->idx = i + 1; } /* Mark entry as used, but we don't know the flavor now. */ if (r != NULL) { r->flavor = ef_us; ++__new_exitfn_called; } return r; }
假设当前调用的处理器是 handler_p,新注册的处理器是 handle_c,从上到下看:
- 因未遍历完所有记录,__exit_funcs_done 未设置,所以仍可以注册新的处理器
- 第一个 for 循环扫描当前块,将刚才回调 handler_p 而设立的 ef_free 记录回退掉
- 如果当前不是第一个记录,则表明并非整个块空闲,直接使用刚设置为 ef_free 的记录,来存储 handler_c 的信息,图 1 展示了这种场景下的状态
- 如果当前是第一个记录,则整个块已空闲,将 idx 设置为 0,并继续向下个块遍历
- 如果下个块为 NULL,表示当前已经是最后一个块,状态见图 2
- 否则继续检查下个块,此时一般不空闲 (一般是满的),见图 3
图 1
图 2
图 3
以上 3 个场景中,每次仅回退一个记录,这是由于我们假设 handler_p 是第一个被调用的处理器,如果它不是第一个被调用的,是否就能出现回退多个记录的场景?
考虑下面这个用例:假设有 handler_3 / handler_2 / handler_1 三个处理器依次被调用,前两个处理器都没有注册新的处理器,handler_1 注册了两个新的 handler,分别为 handler_i / handler_ii。
首先假设 3 个 handler 都在一个块中,注册完两个新 handler 后状态如下图:
图 4
在注册 handler_i 时回退了三次、handler_ii 时回退了两次,因此是可以回退多个记录的,毕竟 __run_exit_handlers 仅仅将遍历过记录的 flavor 设置为 ef_free 而没有修改任何 idx。
下面来看看是否存在跨块回退多个记录的场景,假设 handler_1 与 handler_2 跨块,则调用 handler_1 注册 handler_i 后的状态已变为下图:
图 5
这是因为处理完 handler_2 前一个块已经被释放不可访问了,好在目前 l 指向的块已满且 p == NULL,回退到了当初扩展块时的状态 (注册处理器的场景 3),从而重新分配块和记录,最终效果如图 6:
因为是新分配的块,就不存在覆盖的问题了。
总结一下:
- 可以回退多个记录,但是只限制在一个块内
- p == NULL 时一般是需要分配新的块了
在这个基础上继续执行 __run_exit_handlers,来看新注册的处理器是如何被调用的:
- 首先回顾 __new_exitfn,当它注册新处理器后,会递增 __new_exitfn_called 的值
- 回到 __run_exit_handlers,因检测到 __new_exitfn_called 发生了变化,会 goto restart 重新执行整个 while 循环
- 重新遍历时,会首先处理新加入的处理器,且也是按 FILO 的顺序处理
至此最后一个特性分析完毕。
结语
从这里也可以看到一个标准的 atexit 需要考虑的问题:
- 程序运行期间单向增长
- 程序退出时反向减少
- 有可能在执行回调时注册新的处理器从而导致再次增长,所以并不是单向减少
代码优化
glibc 主要花费了大量的精力处理第三个场景,不过经过本文一番分析,似乎不需要做的如此复杂。
... for (l = *listp; l != NULL; p = l, l = l->next) { for (i = l->idx; i > 0; --i) if (l->fns[i - 1].flavor != ef_free) break; if (i > 0) break; /* This block is completely unused. */ l->idx = 0; } if (l == NULL || i == sizeof (l->fns) / sizeof (l->fns[0])) { /* The last entry in a block is used. Use the first entry in the previous block if it exists. Otherwise create a new one. */ if (p == NULL) { assert (l != NULL); p = (struct exit_function_list *) calloc (1, sizeof (struct exit_function_list)); if (p != NULL) { p->next = *listp; *listp = p; } } if (p != NULL) { r = &p->fns[0]; p->idx = 1; } } else { /* There is more room in the block. */ r = &l->fns[i]; l->idx = i + 1; } ...
例如回退记录实际不存在跨块的可能,那么回退时就可以只考虑当前块了,__new_exitfn 中第一个两层的 for 循环就可以简化为单层:
... l = *listp; for (i = l->idx; i > 0; --i) if (l->fns[i - 1].flavor != ef_free) break; if (i == 0) /* This block is completely unused. */ l->idx = 0; if (i == sizeof (l->fns) / sizeof (l->fns[0])) { /* The last entry in a block is used. Use the first entry in the previous block if it exists. Otherwise create a new one. */ assert (p == NULL); assert (l != NULL); p = (struct exit_function_list *) calloc (1, sizeof (struct exit_function_list)); if (p != NULL) { p->next = *listp; *listp = p; } } else { /* There is more room in the block. */ r = &l->fns[i]; l->idx = i + 1; } ...
经过简化后,l 永远不为 NULL,p 永远为 NULL,第二个 if 段中对 l 和 p 是否为 NULL 的判断就可以去掉了。看起来是不是简洁了一些?
当然了,上面的代码是没有经过验证的,保不齐哪里还有逻辑漏洞,欢迎大家来找茬~
dump exit_function_list
本来是打算把 __exit_funcs 中的内容打印出来看看,然而 glibc 设置了完备的符号隐藏,无法获取这个变量的地址:
extern struct exit_function_list *__exit_funcs attribute_hidden; extern struct exit_function_list *__quick_exit_funcs attribute_hidden; extern uint64_t __new_exitfn_called attribute_hidden; /* True once all registered atexit/at_quick_exit/onexit handlers have been called */ extern bool __exit_funcs_done attribute_hidden;
其中 attribute_hidden 就是设置符号的 visibility 属性:
# define attribute_hidden __attribute__ ((visibility ("hidden")))
例如在示例代码中插入下面的声明:
enum { ef_free, ef_us, ef_on, ef_at, ef_cxa }; struct exit_function { long int flavor; union { void (*at) (void); struct { void (*fn) (int status, void *arg); void *arg; } on; struct { void (*fn) (void *arg, int status); void *arg; void *dso_handle; } cxa; } func; }; struct exit_function_list { struct exit_function_list *next; size_t idx; struct exit_function fns[32]; }; extern struct exit_function_list *__exit_funcs;
并在 main 中打印 __exit_funcs 的地址:
printf ("__exit_funcs: %pn", __exit_funcs);
编译时会报错:
$ make gcc -Wall -g dumpexit.o apue.o -o dumpexit dumpexit.o: In function `dump_exit': /home/users/yunhai01/code/apue/07.chapter/dumpexit.c:70: undefined reference to `__exit_funcs' dumpexit.o: In function `main': /home/users/yunhai01/code/apue/07.chapter/dumpexit.c:103: undefined reference to `__exit_funcs' collect2: error: ld returned 1 exit status make: *** [dumpexit] Error 1
正打算放弃,无意间看到这样一段宏:
#if defined SHARED || defined LIBC_NONSHARED || (BUILD_PIE_DEFAULT && IS_IN (libc)) # define attribute_hidden __attribute__ ((visibility ("hidden"))) #else # define attribute_hidden #endif
看起来符号隐藏只针对共享库,改为静态链接试试:
dumpexit: dumpexit.o apue.o gcc -Wall -g $^ -o $@ -static dumpexit.o: dumpexit.c ../apue.h gcc -Wall -g -c $< -o $@ -std=c99
居然通过了。运行程序,可以正常打印 __exit_funcs 地址:
$ ./dumpexit __exit_funcs: 0x6c74a0
注意这一步需要安装 glibc 静态库:
sudo yum install glibc-static
否则报下面的链接错误:
$ make dumpexit gcc -Wall -g dumpexit.o apue.o -o dumpexit -static /usr/bin/ld: cannot find -lc collect2: error: ld returned 1 exit status make: *** [dumpexit] Error 1
下面增加一些打印的代码:
void dump_exit_func (struct exit_function *ef) { switch (ef->flavor) { case ef_free: printf ("free slotn"); break; case ef_us: printf ("occupy slotn"); break; case ef_on: printf ("on_exit function: %p, arg: %pn", ef->func.on.fn, ef->func.on.arg); break; case ef_at: printf ("atexit function: %pn", ef->func.at); break; case ef_cxa: printf ("cxa_exit function: %p, arg: %p, dso: %pn", ef->func.cxa.fn, ef->func.cxa.arg, ef->func.cxa.dso_handle); break; default: printf ("unknown type: %dn", ef->flavor); break; } } void dump_exit () { struct exit_function_list *l = __exit_funcs; while (l != NULL) { printf ("total %d recordn", l->idx); for (int i=0; i<l->idx; ++ i) { dump_exit_func (&l->fns[i]); } l = l->next; } }
平平无奇的代码,为了增加可读性,事先注册了几个处理器:
void do_dirty_work () { printf ("doing dirty works!n"); } void bye () { printf ("bye, forks~n"); } void times () { static int counter = 32; printf ("times %dn", counter--); } int main () { int ret = 0; printf ("__exit_funcs: %pn", __exit_funcs); ret = atexit (do_dirty_work); if (ret != 0) err_sys ("atexit"); else printf ("register do_dirty_work %pn", (void *)do_dirty_work); ret = atexit (bye); if (ret != 0) err_sys ("bye1"); else printf ("register bye %pn", (void *)bye); ret = atexit (times); if (ret != 0) err_sys ("times"); else printf ("register times %pn", (void *)times); dump_exit (); printf ("main is done!n"); return 0; }
运行后效果如下:
$ ./dumpexit __exit_funcs: 0x6c74a0 register do_dirty_work 0x40115a register bye 0x40116a register times 0x40117a total 4 record cxa_exit function: 0x24a492d7cf90f3f0, arg: (nil), dso: (nil) cxa_exit function: 0x24a492d76ac4f3f0, arg: (nil), dso: (nil) cxa_exit function: 0x24a492d76aa4f3f0, arg: (nil), dso: (nil) cxa_exit function: 0x24a492d76a84f3f0, arg: (nil), dso: (nil) main is done! times 32 bye, forks~ doing dirty works!
看起来有 4 个处理器,然而它们的地址却都一样,和我准备的那三个函数地址完全不同。
不清楚是否因为 glibc 版本变迁,导致 __exit_funcs 的内部结构发生了变化,还是什么其它原因导致成员对齐出了问题,最终没有打印出来预期的结果,有了解的同学不吝赐教。
后记
code browser 已经足够强大,美中不足的是缺少书签功能,在追踪调用栈时回退不是特别方便。
好在 Bing 同学已经贴心的为我们提供了相关的插件:https://github.com/caibingcheng/codebrowser-bookmark
安装之后浏览本文用的到几个关键函数效果如下:
直接点击书签就可以跳转到历史位置了,比之前多次回退方便多了。
实际操作起来非常简单,以我古老的 firefox 为例:
- 安装油猴脚本管理器:https://addons.mozilla.org/zh-CN/firefox/addon/tampermonkey/,这一步基本是安装了一个浏览器 add-on
- 导入书签插件:https://greasyfork.org/zh-CN/import,这一步需要填入 Bing 同学提供的脚本地址 (https://raw.githubusercontent.com/caibingcheng/codebrowser-bookmark/master/index.js),然后点击导入:
在新页面中安装导入的插件:
从弹出的窗口中选择直接安装:
这里会提示安装油猴脚本管理器,如果已经安装可以忽略提示:
点击安装后就可以看到脚本版本了:
回到 code browser,刷新下页面就可以看到书签小窗口啦~
需要注意的是,书签是本地存储的,在一台设备上创建的书签,不会自动同步到另一台设备哦。
参考
[1]. code browser
[2]. glibc-exit源码阅读
[3]. codebrowser书签插件