为什么调试时GNU getopt的optarg为0，赋值使用时却能得到正常值？

问题原因 #

这个现象是GNU C库（glibc）的getopt系列变量实现特性，和GDB的符号解析逻辑共同导致的，和代码逻辑、编译优化无关：

• glibc为了支持多线程安全，将optarg、optind、opterr、optopt这几个getopt相关的变量都存储在线程局部存储（TLS）区域，对外暴露的optarg实际是一个宏，编译阶段会被展开为对当前线程TLS内对应变量的访问，程序运行时实际读写的都是这个TLS内的实例，值是正确的。
• 为了兼容早年未考虑多线程的旧代码，glibc同时保留了一个全局弱符号optarg，这个符号的默认值就是0x0，但现代多线程程序运行时根本不会用到这个全局符号。
• GDB在打印optarg时，默认优先解析全局符号，不会自动处理optarg的宏展开逻辑，所以打印出来的就是那个无用的全局弱符号的值0x0，和代码实际运行时读取的TLS变量不是同一个存储位置。

验证方法 #

你可以通过以下方式确认这个逻辑：

1. 编译时添加-save-temps参数，查看生成的.i预处理后的文件，可以看到代码里的optarg已经被替换为宏展开后的内容，不是直接引用全局变量。
2. 如果编译时添加了-g3参数（生成包含宏定义的调试信息），可以在GDB中执行macro expand optarg查看optarg实际展开后指向的TLS变量，打印这个展开后的变量就能拿到正确的值。
3. 直接在代码中插入printf("optarg address: %p, value: %s\n", optarg, optarg);，运行后输出的就是和cvalue一致的正确值。

内容的提问来源于stack exchange，提问作者Peter