Windows链接器符号匹配规则及自定义链接器符号解析问题

我正在编写一款Windows平台的自定义链接器。用cl.exe编译简单的"hello world"程序后，自定义链接器链接失败，但link.exe可以正常完成链接。生成的目标文件里有未定义符号?_OptionsStorage@?1??__local_stdio_printf_options@@9@9，而libcmt.lib中存在相似符号?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA。用undname.exe解混淆后，两者仅类型声明有差异。

我有以下问题：

1. 如何确认link.exe是否使用上述libcmt.lib中的符号解析目标文件的未定义符号？用/VERBOSE和/MAP参数没获取到相关信息。
2. 若该符号确实被选中，为何名称不完全一致仍可匹配？
3. 自定义链接器应采用何种检查方式替代简单字符串比较以实现可靠的符号解析？

问题1解答 #

可以通过两种方式验证：

• 使用link.exe的/VERBOSE:SYMBOLS参数，该参数会输出更详细的符号匹配日志，能明确看到未定义符号是从哪个库的哪个目标文件中被解析的；
• 借助dumpbin.exe工具分步验证：
  1. 执行dumpbin /SYMBOLS <目标文件.obj>，确认未定义符号?_OptionsStorage@?1??__local_stdio_printf_options@@9@9存在；
  2. 执行dumpbin /ARCHIVEMEMBERS libcmt.lib，定位到包含相似符号?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA的具体.obj文件；
  3. 链接时仅指定这个.obj文件（而非整个libcmt.lib），如果链接成功，即可证明link.exe确实使用了该符号。

问题2解答 #

这是因为MSVC链接器对特定符号的匹配规则存在放宽：

• 名称差异源于MSVC的名字修饰规则，解混淆后的类型差异大概率是CV修饰符（const/volatile）或存储类的区别；
• 对于__local_stdio_printf_options这类编译器生成的内部辅助符号（用于静态局部变量的存储），MSVC链接器会忽略那些不影响内存地址绑定的修饰差异——这类符号的实际内存实例是唯一的，只要核心标识一致，即使CV修饰或存储类标记不同，也会被判定为可匹配；
• 符号后缀中的@9和@4_KA，其中4代表存储类，KA代表const unsigned long类型，而目标符号的@9对应的非const类型，属于链接器允许的兼容匹配范畴。

问题3解答 #

要实现可靠的符号解析，必须放弃简单字符串比较，转而基于MSVC名字修饰的语义进行匹配：

• 实现MSVC名字修饰解析逻辑，从修饰符号中提取核心信息：包括符号所属的内部标识（如__local_stdio_printf_options）、变量/函数的本质类型、CV修饰符、存储类等；
• 区分符号类型：对于编译器生成的内部辅助符号，放宽CV修饰符、存储类的匹配要求；对于用户自定义符号，则严格匹配所有类型和修饰信息；
• 参考微软公开的MSVC名字修饰规范，确保解析逻辑符合官方规则，重点匹配符号的唯一实例标识，而非字面量字符串。

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