一、开发流程

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 }
View Code
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 }
View Code
1 #include "test.h"
2 
3 int main()
4 {
5         test_so();
6 }
View Code

编译 & 链接 & 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 2023-02-13 20:29  莫扎特的代码  阅读(8429)  评论(0编辑  收藏  举报