一、开发流程
1. 编译可执行文件
1 #include <stdio.h> 2 #include <unistd.h> 3 4 void test() 5 { 6 char * s = "hello world\n"; 7 while(1){ 8 //int v = 0/0; 9 printf("%s\n", s); 10 sleep(1); 11 } 12 } 13 14 int main() 15 { 16 test(); 17 }
2. 生成独立的调试符号文件
gcc -ggdb3 test.c -o test
3. 删除可执行文件内的调试符号
objcopy --only-keep-debug test test.debug strip --strip-debug --strip-unneeded test
4. 一般情况
在 ELF 文件内埋桩指定符号文件，gdb 就可以在调试的时候自动加载调试符号了：
objcopy --add-gnu-debuglink=test.debug test
在 ELF文件内也可以看到 .gnu_debuglink 段内保存的调试符号文件。
但是，当我们换了调试环境，或者符号文件路径和 ELF 文件内的路径不匹配的时候，就会报符号找不到的错，这时候仍然需要手动处理符号文件。
二、开始gdb调试
未通过 .gnu_debuglink 指定符号文件时，通过 bt 查看进程的调用栈，我们会看到缺失的符号无法解析。gdb 执行 bt 指令时， 会拿地址信息在已知的符号表内搜索最接近的地址。显示问号，就是说 gdb 完全找不到接近的符号，这时候，我们通过 info symbol [address] 指令也是得不到地址对应的符号信息的。
尝试手动加载调试符号文件
gdb 需要知道 [symbol] -> [address] 的映射信息，而 gdb 正好提供了 symbol-file 和 add-symbol-file 指令来手动添加这个信息。因此，我们要做的就是把 .debug 文件内的符号信息告诉 gdb 。先看下 .debug 文件内保存的符号信息：
其中 _start 符号是个特殊的符号，一般是 ELF 文件的入口。通过 readelf -h 命令，我们可以看到 ELF 文件的入口地址与 _start 符号地址是相同的。
该地址也是 readelf -S 输出的 .text 段的地址
很明显，这里的地址和 bt trace 里的地址相差甚远，由于操作系统的保护机制（ASLR） ，ELF 文件并不会直接加载到这个地址，而是会加载到一个随机地址上。因此，我们需要找到这个地址，并把符号表内所有符号的地址都加上这个偏移量（gdb 应该也是可以自动完成这个操作的？）
找到 .text 段加载的位置：
通过 cat /proc/[pid]/maps 我们可以获得进程内存镜像内所有段信息，其中以 ELF 文件名命名并且带有可执行权限的段，就是该 ELF 文件 .text 段加载的地址，这也是我们希望 gdb: info address _start 指令得到的地址。
gdb 加载调试符号：
由于我们的目标是让 gdb 解析 .text 段地址为 addr(.text) ， 也就是这里的 0x56266ea06000, 而当前符号文件内的 .text 段地址是 addr(elf.entry_point)，也就是 0x1060，所以我们偏移量的计算方法是：
addr(.text) - addr(elf.entry_point)
添加符号文件指令： symbol-file xxx.debug -o offset
给个调试符号文件，给这个调试文件一个偏移地址，gdb加载符号文件的时候，会自动把符号对应的地址都加上这个偏移量。
ok， 符号解析出来了，查看对应内存上的数据和 ELF文件内的数据是对的上的。
看下 trace，诡异，仍然不对...
detach & attach 后一切正常了，似乎是 gdb 的一个bug，先attach后加载符号文件会有问题。
如果需要解析 ELF 的其它 section 同理 ... 似乎写个脚本自动处理更好~
三、动态加载的SO添加符号文件：
代码：
1 #include <stdio.h> 2 #include <unistd.h> 3 #include "test.h" 4 5 static void test() 6 { 7 char * s = "hello so\n"; 8 while(1){ 9 printf("%s\n", s); 10 sleep(1); 11 } 12 } 13 14 void test_so() 15 { 16 test(); 17 }
1 #include "test.h" 2 3 int main() 4 { 5 test_so(); 6 }
编译 & 链接 & strip：
gcc test.c -ggdb3 -shared -fPIC -o libtest.so gcc test.c -ggdb3 -shared -o libtest.so objcopy --only-keep-debug libtest.so libtest.so.debug strip --strip-debug --strip-unneeded libtest.so
开始加载调试符号：
我最开始是按照上面主程序的方法，从 /proc/pid/maps 找到动态库加载的地址来计算偏移量的，但是失败了，符号解析的地址和内存内的地址总是差几十个字节。
最后发现，通过 gdb info shared 获得的链接库地址和 maps 内的地址有点不同：
用这个地址计算得到的符号文件偏移量是正确的。
/proc/pid/maps 提示 .text 段在 0x7f931b532000，info shared 提示动态库被加载的地址是 0x7f931b532060，看下这部分内存放的到底是啥。.text 段确实加载到了 0x7f931b532060，那么在这之间的内存放的是什么呢？其实，从名字上也应该猜出来了，应该是链接的时候添加的 plt 相关的处理代码。
googles 上有好多处理这种自动计算符号文件偏移量的代码，例如
https://stackoverflow.com/questions/20380204/how-to-load-multiple-symbol-files-in-gdb。但是我试了下，在我的环境下都不太可行。这些代码，有的只拿 elf 文件的 .text 段地址来计算，有的只拿进程内的段加载地址，很明显和我的环境都不搭。这个可能是和 gdb 实现的具体逻辑有关？毕竟 gdb 是能够获取这些地址信息并自动帮我们处理的。
总结:
gdb 单独指定符号文件时，原则是要 ELF 文件的 .text 段和进程镜像里的 .text 段加载地址匹配上，需要根据具体环境计算相关的偏移量，不可盲信 google 上的相关代码啊~
posted on
