作者：gfree.wind@gmail.com
博客：blog.focus-linux.net linuxfocus.blog.chinaunix.net
博客：blog.focus-linux.net linuxfocus.blog.chinaunix.net
本文的copyleft归gfree.wind@gmail.com所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。
======================================================================================================
今天这个主题有点意思，各位同学听我慢慢道来。
当我们使用GDB调试一个daemon的时候，一般有两种方式：
1. 直接在shell命令行键入gdb attach pid （要调试daemon的进程ID）。一般情况下，我都习惯于缩写gdb at pid；
2. 在shell中键入gdb，进入gdb，然后attach pid（同样是要调试daemon的进程ID）。我不常用这种方式，因为这种方式需要2个步骤——尽管键入的字母是一样的。
下面来说说今天遇到的问题。公司的一个实习生来问我问题。他目前正在做一个工作，大致的功能是得到某个daemon的某一时刻的调用栈——就像gdb一样。但是他发现当daemon处于系统调用状态时，从EBP得到的返回地址不正确。然后我让他直接使用gdb查看是否可以看到完整的调用栈，如果GDB可以，那么就没有问题，可以去看GDB如何实现的。如果不能，再想为什么。——这里先插一句，当时我去查看了他的EBP的值，根据其值获得的返回地址确实不正确。今晚查了查，知道在某些函数调用时，为了速度，EBP有可能并没有被压栈。但是这个不是今天的主题，让我们再转回来。他很快的试了试，告诉我gdb虽然可以使用bt(backtrace)得到函数栈，但是显示出来的结果却不正确。
怎么回事呢？不可能啊。我在他那写了一个很简单的测试程序：
- #include <stdlib.h>
- #include <stdio.h>
- static void test(void)
- {
- pause();
- }
- int main(void)
- {
- test();
- return 0;
- }
编译并运行：
- [xxx@xxx-vm-fc13 test]$ gcc -g test.c
- [xxx@xxx-vm-fc13 test]$ ./a.out
然后使用另外一个终端进行调试：
- [xxx@xxx-vm-fc13 test]$ ps auwx|grep a.out
- xxx 2412 0.0 0.0 1816 288 pts/4 S+ 11:19 0:00 ./a.out
- xxx 2415 0.0 0.0 4308 732 pts/5 S+ 11:20 0:00 grep a.out
- [xxx@xxx-vm-fc13 test]$ gdb at 2412
- GNU gdb (GDB) Fedora (7.1-18.fc13)
- Copyright (C) 2010 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "i686-redhat-linux-gnu".
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>...
- Reading symbols from /usr/bin/at...(no debugging symbols found)...done.
- Attaching to program: /usr/bin/at, process 2412
- Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
- Loaded symbols for /lib/ld-linux.so.2
- 0x009f4424 in __kernel_vsyscall ()
- Missing separate debuginfos, use: debuginfo-install at-3.1.12-5.fc13.i686
- (gdb) bt
- #0 0x009f4424 in __kernel_vsyscall ()
- #1 0x0065dac6 in ?? ()
- #2 0x080483dc in ?? ()
- #3 0x005d6cc6 in ?? ()
- #4 0x08048331 in ?? ()
- (gdb)
看到这个结果，我还真有些意外。我使用gdb也有些年头了，从来都是这样调试daemon的啊。怎么会这样呢啊？看这个输出，很像没有调试信息啊。可是前面的编译有-g选项啊。
使用第二种方法试试？
- [xxx@xxx-vm-fc13 test]$ gdb
- GNU gdb (GDB) Fedora (7.1-18.fc13)
- Copyright (C) 2010 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "i686-redhat-linux-gnu".
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>.
- (gdb) at 2412
- Attaching to process 2412
- Reading symbols from /home/fgao/works/test/a.out...done.
- Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
- Loaded symbols for /lib/libc.so.6
- Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
- Loaded symbols for /lib/ld-linux.so.2
- 0x009f4424 in __kernel_vsyscall ()
- Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.i686
- (gdb) bt
- #0 0x009f4424 in __kernel_vsyscall ()
- #1 0x0065dac6 in __pause_nocancel () from /lib/libc.so.6
- #2 0x080483cf in test () at test.c:6
- #3 0x080483dc in main () at test.c:12
- (gdb)
啊，这种方式就没有问题啊。怎么回事呢？难道是因为这两种方式的attach还有区别不成？于是我又查了gdb的说明，应该没有区别啊。
想了半天，又试了几次第一种方式，还是没有结果。当我感觉我以前的GDB的世界观都要崩溃的时候，对自己的GDB技能产生了极度的不自信的时候，再次退出gdb的时候，我发现了原因。该原因差点没把我郁闷死。。。
大家想一下哦。。。
- (gdb) q
- A debugging session is active.
- Inferior 1 [process 2412] will be detached.
- Quit anyway? (y or n) y
- Detaching from program: /usr/bin/at, process 2412
注意看这里的红色代码。进程号没有错，但是program却是/usr/bin/at。My god！原来我使用第一种方式的时候，一直在尝试调试at——这个linux命令。怪不得没有调试信息呢！在我以前的GDB应用中，因为系统中没有at这个命令，所以gdb at pid就等于gdb attach pid，是可以缩写的。但是在当前这个环境中，很并不幸的存在着at这个命令。结果GDB没有尝试去attach，而是直接去调试at命令。
不过这里，我觉得GDB可以做得更友好一些。虽然在这个情况下，GDB去调试at没有问题，但是后面的PID已经被我的测试程序占用了，它应该报个错误或者警告吧。
最后总结一下，GDB的缩写是好，但是小心过分的缩写会与已有命令冲突哦~~总之，缩写需谨慎。
