Bootstrap

GDB如何从Coredump文件恢复动态库信息

[原创]转载请注明来源于CSDN _xiao。

Linux生成Coredump文件时程序并没有对动态链接库文件信息进行特殊处理,但GDB在载入Coredump文件时却能正确加载所有的动态链接库,包括程序运行中调用dlopen动态载入的so文件,其原理是什么呢?这里通过对GDB源码的略览来解开这个过程。

[关于如何设置库搜索路径以及路径搜索的优先级可参考"GDB动态库搜索路径"笔记]

GDB的大略架构:gdb.c中的main函数是程序的入口,它只是简单地调用gdb_main,后者再调用captured_maincaptured_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,并调用targetopen函数处理。corelow.c在初始化时注册了该类型的target,所以会进入corelow.ccore_open函数。core_open函数调用bfd_fopen函数打开该文件(bfd_fopen会识别格式并按ELF格式打开),然后调用build_section_table

;