本文共 1834 字,大约阅读时间需要 6 分钟。
最近看了一篇getopt使用的文章,为了追踪其执行的逻辑,于是采用GDB挂载调试的方式进行查看。但却出现了GDB打印全局变量optind的时候出现错误。
首先optind是使用getopt时候的全局变量,表示使用getopt时候的下一个argv的指针索引。在应用程序调试的时候设置了多个参数,但是随着多次调用getopt,全局变量optind通过gdb打印出来的值却总是1, 但是通过程序打印出来的optind确实是逐步变化的。奇怪了,gdb怎么会有这么明显的bug呢?
于是我在程序中打印出optind的地址为0x600D60.
+++++++++++++++++++++
The optind address is 0x600d60.
+++++++++++++++++++++
那么我们看看gdb打印出来的optind的地址又是多少呢? 如下所示,OMG,他们的地址居然不一样!
+++++++++++++++++++++
(gdb) p &optind
$1 = (int *) 0x3bcfd5210c+++++++++++++++++++++
根据多方面的探索,后来查看到,这个涉及到一个“Copy Relocation”的技术。也就是动态库中存在全局变量的时候,在编译阶段已经在程序的.BSS段中预留了控件给动态库中的全局变量,然后当程序初始化的时候,会拷贝动态库中的全局变量到程序预留的.BSS段控件;其他所有的动态库,也将访问通过前面所说的.BSS段中的全局变量来访问原先动态库中定义的全局变量。 具体关于Copy Relocation的机制可以参考文章:http://www.shrubbery.net/solaris9ab/SUNWdev/LLM/p22.html#CHAPTER4-84604
回到原先的问题,那么GDB打印出来并不是程序中.BSS通过Copy Relocation产生的全局变量optind, 而是打印的libc.so中原有的变量的值。
那么怎么打印出正确的值呢?
首先我们通过"Info var optind"查看下optind相关的信息,可以看到两处指名了optind的出处,第一处其实说明了这个是在libc.so中定义的,而gdb默认打印的也是libc.so中定义的,第二处就是之前所说的通过"Copy Relocation"技术存储的optind的实际使用的地址,其地址也是"0x600D60"。
++++++++++++++++++++
(gdb) info var optind
All variables matching regular expression "optind": File /usr/include/getopt.h: static int optind; Non-debugging symbols: 0x0000000000600d60 optind@@GLIBC_2.2.5++++++++++++++++++++
现在我们就可以通过命令[p 'optind@@GLIBC_2.2.5']打印出实际使用的optind的值。
其实一个简单的问题背后,会隐藏着很多技术和机制。而要真正的明白问题产生的根本原因,目前所掌握的知识还远远不够,楼主一定还需再接再厉。以后还会针对这个问题引申出来的GOT,Copy Relocation等好好的研究研究。
1. gdb does not print right value!
http://www.linuxquestions.org/questions/programming-9/gdb-does-not-print-right-value-908538/
2. optind
https://sourceware.org/ml/gdb/2003-12/msg00160.html
3. Copy Relocation
http://www.shrubbery.net/solaris9ab/SUNWdev/LLM/p22.html#CHAPTER4-84604
4. What's the purpose of copy relocation?
http://stackoverflow.com/questions/26863009/whats-the-purpose-of-copy-relocation转载地址:http://ougoz.baihongyu.com/