快！这是关于"Segmentation fault"的最后一趟车！

在该系列的第一篇文章中已经教给大家一个通用的方法就是利用backtrace函数和addr2line命令定位问题，戳这里查看如何轻松搞定“Segmentation fault”，看这篇就够了！

 

至于如何把gdb异常调用栈不包含动态库的实现方法移植到任意平台（ARM/MIPS...）的方法，需要复习的小伙伴看这里：大招！如何把Gdb异常调用栈功能移植到任意平台？

 

今天主要分析包含动态库的异常调栈，如何实现。

 

先看下异常调用栈包含动态库的情况下gdb下bt的显示结果：

 

这个打印后三行的实现，前面几篇文章已经分析了。今天主要是讲第一行，对于调用栈包含动态库，需要打印出文件名和函数名，这里为什么没有行号？你可以结合编译原理去思考下呢。

 

下面需要做的就是自己编码实现这个功能，并应用于各种平台（ARM/MIPS...）。

 

前面讲过，当系统抛出异常，会触发异常调用函数，在该函数内线调用backtrace函数获取调用栈信息，然后执行dump_backtrace可以打印出异常栈。

 

在dump_backtrace里，先打开一个fd，然后根据addr，调用dump_current_pc_location进行地址解析。

 

具体到本文目的，修改点涉及两点。

 

第一，打开的fd，不一定是可执行文件本身，也可能是该可执行文件依赖的动态库，如何去判断？

 

第二，在dump_current_pc_location里获取符号表，需要区分是静态文件符号表还是动态库的符号表。

 

先解决第一个问题，首先我们知道每个可执行文件有个地址映射表，这个映射表可以通过/proc/pid/maps节点获取到，如下图所示：

 

例如0x7ffff7bd9000-0x7ffff7bda000存放的是libtest.so。如果异常栈地址正好落在这个范围，则这个地址属于libtest.so。

 

是不是有人会质疑上图libtest.so信息明明有四行，为什么我们这里需要解析的地址不会在其他三行？

 

简言之，第一行是libtest.so的可执行的代码段。具体原理可以参考前面讲的动态补丁机制文章。

 

下面我们可以把调用backtrace获取的栈地址打印出来，如下所示：

 

我们可以找到0x7ffff7bd9688这个地址，这个地址在0x7ffff7bd9000-0x7ffff7bda000中，它属于libtest.so。所以我们在解析这个地址时，打开的文件就是打开libtest.so获取fd。

 

根据之前文章讲的公式“动态库地址=动态库的基地址（随机分配）+ 地址偏移”。所以给dump_current_pc_location传递的pc，是一个偏移地址，需要将0x7ffff7bd9688减去libtest.so的基地址。在maps表中，可知libtest.so的基地址是0x7ffff7bd9000。

 

这样dump_current_pc_location两个入参都已针对动态库做了修复。dump_current_pc_location里还有一个地方需要小改下，因为bfd库动态库获取符号表的函数有些不同，需要调用bfd_get_dynamic_symtab_upper_bound和bfd_canonicalize_dynamic_symtab取获取动态库符号表。

 

此时，我们的剩余工作就是根据0x7ffff7bd9688这个地址怎么用代码实现找到libtest.so及其基地址。

 

回顾下我们手动怎么找的？

 

在maps中遍历每个已经加载的共享对象，如果目标地址属于某共享对象的地址范围，则大功告成！

 

Linux有一个实现这个功能的函数，即dl_iterate_phdr，它遍历每个已经加载的共享对象，并需要自己封装一个回调接口，来做地址是否在一个区间的判断操作，如下代码就是这个回调。

 

编码完，我们进行了验证，同时打印了0x7ffff7bd9688的归属，如下所示：

 

至此整个dump异常调用栈功能已经全部实现。

 

欢迎扫码关注，一起学习Linux