本文共 1228 字，大约阅读时间需要 4 分钟。

今天遇到了一个挺有意思的问题，涉及到GDB调试和getopt的使用。我为这件事做了一些调试，但遇到了困惑，所以决定仔细分析一下。

首先，optind是什么？在getopt库中，optind是一个全局变量，用于跟踪getopt解析后的下一个ARGV指针索引。它应该是整数类型。在我的调试过程中，通过程序内部打印optind，发现它的值确实在不断变化，这说明全局变量是被正确地更新的。

接下来，问题出现在GDB的打印结果。使用gdb的p命令打印optind时，发现其值总是1。这个现象明显不对，因为程序内部显示的值并非如此。于是，我开始检查GDB的打印结果，看看是否有哪里弄错了。

在进一步的调试中，我查看了gdb的输出，发现当用p &optind时，打印的地址确实是0x600d60，这与程序内部的打印结果一致。但使用p &optind的时候，它显示的是一个整数1。这种情况让我困惑，因为0x600d60不应该是1的值。

于是，我思考可能的原因。由于程序是动态链接库加载的，可能涉及到不同的加载地址或者符号解析的问题。我记得在动态链接库中，变量有时会有不同的行为，特别是当它们被多个库同时访问时。

接下来，我查阅了相关资料，发现这可能涉及到一个叫做“Copy Relocation”的技术。这个技术用于处理动态链接库中的全局变量。当程序运行时，动态链接库中的全局变量需要被复制到本程序的.BSS段中，以便其他库可以通过这里访问它们。

在ptrace和glibc的源码中，我找到了一些线索，解释了当getopt解析命令时，optind是在程序的.BSS段中被设置的，而GDB打印的值是直接从glibc中查找的，这与实际运行中的变量有关联。

于是，我尝试使用gdb的info var optind命令，查看optind的定义情况。发现optind有两个定义：一个在getopt.h中作为static int声明，另一个是non-debugging符号，位于0x0000000000600d60处，标记为GLIBC_2.2.5版本。

这里，我意识到gdb默认打印的是从glibc中获取的optind值，而不是程序运行时真正被使用的值。为了让gdb打印正确的optind值，我开始尝试使用带版本号的打印指令p 'optind@@GLIBC_2.2.5'。这次，打印的结果正确反映了程序内部的实际值，而不是固定值1。

通过这一系列的调试步骤，我理解了GDB在处理动态链接库中的全局变量时的复杂性以及Copy Relocation技术的作用。这次经历让我对glibc内部的变量管理和GDB调试技巧有了更深入的理解。

总的来说，这个问题主要是由于GDB默认查看的是glibc中的global offset table中的值，而不是程序运行时真正使用的值。通过正确的打印方式，我成功获取到了正确的optind值。这也提醒我在未来的调试中要更仔细地了解库的加载和变量管理机制。

转载地址：http://ougoz.baihongyu.com/