原帖：http://blog.csdn.net/_xiao/article/details/23177577
版权声明：本文为博主原创文章，未经博主允许不得转载。
[原创]转载请注明来源于CSDN _xiao。
在Linux生成Coredump文件时程序并没有对动态链接库文件信息进行特殊处理，但GDB在载入Coredump文件时却能正确加载所有的动态链接库，包括程序运行中调用dlopen动态载入的so文件，其原理是什么呢？这里通过对GDB源码的略览来解开这个过程。
[关于如何设置库搜索路径以及路径搜索的优先级可参考"GDB动态库搜索路径"笔记]
GDB的大略架构：gdb.c中的main函数是程序的入口，它只是简单地调用gdb_main，后者再调用captured_main，captured_main是执行的主体函数。它先解析命令行参数选项，再初始化所有变量和所有文件，最后是一个while循环，这个循环里不断调用captured_command_loop来获取输入的命令并执行命令所指示的动作。其中初始化时gdb_init会调用initialize_all_files函数来初始化所有文件，这个函数在编译之前是看不到的，在编译时Makefile会扫描所有源文件，将所有类型为initialize_file_ftype的函数搜集起来，放在gdb目录下新生成的init.c文件中，并在此文件中创建initialize_all_files函数，此函数依次调用每一个_initialize_xxx函数。模块在自己的_initialize_xxx函数中除了初始化自身外，还会调用add_cmd或类似的函数来注册命令，之后用户输入所注册的命令时就会调用模块的处理函数了。例如corefile.c文件在_initialize_core函数中注册了"core-file”命令，命令的处理函数是core_file_command，这样当用户敲入"core Coredump”时就会调用core_file_command函数来处理了（"core”是"core-file”命令的别名）。同样exec.c注册了"file”指令，其处理函数为file_command。通常，命令"xxx”的处理函数名为"xxx_command”，例如"info sharedLibrary”命令的处理函数为info_sharedlibrary_command，根据此规则，可以快速找到命令的处理函数。
载入一个Coredump文件时，由core_file_command来处理，首先通过find_core_target来查找有能力处理"CORE”文件的target，并调用target的open函数处理。corelow.c在初始化时注册了该类型的target，所以会进入corelow.c的core_open函数。core_open函数调用bfd_fopen函数打开该文件（bfd_fopen会识别格式并按ELF格式打开），然后调用build_section_table读入Coredump文件的所有sections信息（即segments信息），完成后调用push_target将core的target操作添加到target链表中（这样类似于readmemory等的一些动作就可以在Coredump文件的地址空间进行了）。最后调用post_create_inferior进行后处理，调用init_thread_list读取PT_NOTE信息段中的线程信息，调用target_fetch_registers读取寄存器信息，并根据寄存器恢复调用帧(frame)，最后调用print_stack_frame打印帧信息（即backtrace），整个Coredump文件的载入就完成了。
对于如何恢复动态链接库信息，我们需要关注的是post_create_inferior函数。在这个函数里，如果在core指令之前已执行了file或exec_file命令，即已拥有了主执行程序的信息，那么就会调用solib_add来添加所有的so库。
可见，恢复动态链接库信息的前提是必须拥有Coredump文件和原始主执行程序的Binary文件，如果只有其中一个，是不能恢复动态链接库信息的。
继续看solib_add函数，它主要调用update_solib_list来更新所有的so库列表，在update_solib_list函数里，关键的地方是调用ops->current_sos函数来获取so库信息列表，而current_sos函数总是根据当前信息重建so库列表。
在不同的操作系统和体系架构上，会有不同的current_sos实现。对于工程中通常使用的ARM指令和MIPS指令上的Linux系统，会由svr4_current_sos函数来实现重建功能。
进入svr4_current_sos函数，首先调用locate_base获取调试信息的基址。它调用elf_locate_base分析主执行程序的ELF文件得到该信息。elf_locate_base先调用scan_dyntag查找类型为DT_MIPS_RLD_MAP(0x70000016)的动态信息，如果失败再调用scan_dyntag查找类型为DT_DEBUG(21)的动态信息。对于MIPS，编译器用DT_MIPS_RLD_MAP信息存放调试信息，而DT_DEBUG信息是无意义的，对于其他平台如ARM，则用DT_DEBUG信息存放调试信息，没有DT_MIPS_RLD_MAP信息。san_dyntag读取名为".dynamic”的section并逐一扫描，该section的内容由dynamic section structure数组组成，每个structure由两个整数组成，第一个整数是dynamic的类型（例如DT_DEBUG），第二个整数是dynamic的值，值的意义与类型相关。scan_dyntag逐一扫描，找到类型为DT_MIPS_RLD_MAP的动态信息，然后返回其值。该值是在编译时已经计算好的，实际上其值总是名为".rld_map”的section的地址。elf_locate_base会读取scan_dyntag返回的值所指向的内容，也就是".rld_map” section的内容。".rld_map” section的长度只有4字节，其内容是调试信息的基址，指向dynamic linker structs。在编译时，".rld_map”的值为0，在运行时，由加载器填写其值，加载器会维护一个dynamic linker structs，地址就放在".rld_map”中。在linux中，加载器通常是ld.so或者ld_linux.so。locate_base将elf_locate_base返回的值赋给全局变量debug_base，这样debug_base就指向了dynamic linker structs。由于这个信息是运行时才有的，所以GDB只有在同时载入主执行文件和Coredump文件后才能恢复这个链表。
svr4_current_sos再调用solib_svr4_r_map从dynamic linker structs中获取link map list链表，由于不同平台上数据的组织不同，GDB在读取信息时会调用svr4_fetch_link_map_offsets等函数来获取各变量的偏移地址和尺寸，在mips中，它最终会通过svr4_ilp32_fetch_link_map_offsets提供的信息来解析结构体的数据。在这里r_map_offset的信息为4，所以solib_svr4_r_map从debug_base + 4的地方读取link map list信息，这样就得到了整个链接映射表的头指针。
然后svr4_current_sos开始遍历link map list，这里链表每个元素为20字节，其大概的结构如下（在不同平台上其大小和位置是不同的）：
U32 l_addr; // 4 bytes
U32 l_name; // 4 bytes
U32 l_ld; // 4 bytes
U32 l_next; // 4 bytes
U32 l_prev; // 4 bytes
GDB从Coredump文件中读取链表所在内存中的值，l_name是模块名称的地址，从所指地址即可读出so库文件的名称，l_addr则是模块的加载地址，l_next是下一个模块链接信息的地址，svr4_current_sos逐一遍历，将所有so库文件的名称和信息重建为struct so_list结构的链表，最后返回这个链表。
之后回到update_solib_list函数，这个函数扫描从current_sos返回的so库链表，检查哪些so库已加载，哪些so库需要重新加载，哪些已加载的so库需要卸载掉，然后对每一个需要加载的so库调用solib_map_sections将这些so库映射到target的内存空间。加载so库时会调用tilde_expand和solib_open来扩展库文件名，如果设置了正确sys_root路径和库搜索路径，库就能正确找到和加载。
在所有库都加载到target的内存空间后，整个进程的内存镜像就恢复到Coredump时的状况了，然后就可以观察Coredump时的变量和状态信息了。
GDB加载动态库信息的过程示意如图1所示。
图（1）库文件信息加载过程示意图
下面用一个测试例子来描述库信息的恢复过程。
该示例程序由两个文件组成，一个主程序，一个动态so库，主程序调用动态so库里的一个函数，动态库里的函数操作一个空指针以生成Coredump。
主程序，编译后生成gdbso：
动态库程序，编译后生成libddd.so：
编译主程序和动态库，在MIPS平台上运行生成Coredump，然后用GDB载入主程序gdbso和Coredump文件，载入前使用set sys_root和set solib_search_path设置正确的库搜索路径。
在GDB中，使用"set debug target 10”可以打开加载target时的调试信息，观察GDB是如何加载文件的。
根据CORE加载过程，GDB会读取主程序gdbso的".dynamic” section内容，我们使用objdump –h指令查看gdbso的section信息，如图2所示。
图（2）gdbso的objdump结果
从objdump的结果看到，.dynamic section在文件中的偏移地址为0x017C，在加载后内存中的地址为0x0040017C，这段数据是只读的，所以在内存中的数据与文件中的数据是相同的。我们在GDB中通过"x /28w 0x0040017c”查看.dynamic section的内容，如图3所示。
图（3）.dynamic section的内容
从.dynmaic section的内容看到，地址0x004001dc就是DT_MIPS_RLD_MAP信息，其类型为0x70000016，值为0x00410ac0，这刚好是.rld_map section的地址，与前文所述一致。
再使用"x /w 0x00410ac0”查看.rld_map section的内容，如图4所示。
图（4）.rld_map section的内容
可以看到，.rld_map section的内容为0x2aad7a10（该section是可写的，在文件中的值为0x00000000，在Coredump载入后内存中的值为0x2aad7a10），所以dynamic linker structs的基地址为0x2aad7a10。
使用"x /4w 0x2aad7a10”查看dynamic linker structs的内容，如图5所示。
图（5）dynamic linker structs的部分内容
根据前文分析，在dynamic linker structs中，偏移地址为4的地方就是link map list的地址。所以图5中链接映射表(link map list)的头指针为0x2aad7a28。链表的每个元素是20个字节，使用"x /8w 0x2aad7a28”查看第一个链表元素的内容，如图6所示，注意其中只有前20个字节是有效的。
图（6）link map第一个元素的内容
从图6看到，第一个链表元素的l_addr为0x00000000，l_name为0x2aac47e8，l_ld为0x0040017c，l_next为0x2aac75f8，l_prev为0x00000000。此模块的加载地址为0x00000000，表示是主程序gdbso的模块信息，所以忽略掉它，看下一个链表元素。
使用"x /8w 0x2aac75f8”查看第二个链表元素的内容，如图7所示。
图（7）link map第二个元素的内容
从图7看到，第二个链表元素的l_addr为0x2aad8000，l_name为0x2aac75e8，l_ld为0x2aad818c，l_next为0x2aac7958，l_prev为0x2aad7a28。该模块的加载地址为0x2aad8000，模块名称地址为0x2aac75e8。使用"x /4w 0x2aac75e8”和"x /s 0x2aac75e8”查看该地址的内容，如图8所示，可以看到，该模块的名称为"/lib/librt.so.1”。
图（8）link map第二个元素的模块的名称
按上面的方式，继续根据l_next浏览链表中的每一个模块，直到l_next为0x00000000，如图9所示。
图（9）link map后续元素的解析
从图9看到，整个link map list，包含了"/lib/librt.so.1”、"/lib/libm.so.6”、"/lib/libpthread.so.0”、"/lib/libc.so.6”、"/lib/libdl.so.2”、"/lib/ld.so.1”、"./libddd.so”共7个模块的信息。
从最后一个元素看到，动态库libddd.so被加载到地址0x2ad1a000处，这是整个模块的加载地址，并不是其代码段的加载地址。我们使用objdump查看libddd.so的.text段的偏移信息，如图10所示。
图（10）libddd.so的objdump结果
从图10看到，libddd.so的.text在内存中的偏移为0x0590，所以该模块加载到地址0x2ad1a000之后其代码段会被加载到0x2ad1a590处。
我们用"info sharedlibrary”查看GDB解析的结果，和我们的分析是一致的，如图11所示。
图（11）GDB的info sharedlibrary结果
至此，整个so库信息加载过程就完成了。
