如何配置MinGW64 GCC的DLL导入调用风格？为何用寄存器中转调用？

测试代码 #

#include <windows.h>
int main() {
    Sleep(1);
    return 0;
}

各编译器编译结果 #

GCC（MinGW-W64） #

编译命令：

gcc -m64 -o main.exe main.c

生成的汇编指令：

mov rax, [<Sleep>]
call rax

这里的<Sleep>指向.idata段的地址。

MSVC & Clang #

MSVC编译命令：

cl main.c

Clang编译命令：

clang -o main.exe main.c

二者生成的汇编完全一致：

call [<Sleep>]

此处<Sleep>指向.rdata段的地址。

环境中的编译器版本 #

• GCC：gcc version 14.2.0 (MinGW-W64 x86_64-ucrt-posix-seh)
• MSVC：Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34809 for x64
• Clang：clang version 18.1.8, Target: x86_64-pc-windows-msvc

1. 让GCC生成直接调用指令的方法 #

有两种可行方式：

• 添加-fno-indirect-call-ret编译选项：这个选项会关闭GCC针对间接调用的特定优化，强制生成call [<Sleep>]这种直接调用指令。修改后的编译命令：

  gcc -m64 -fno-indirect-call-ret -o main.exe main.c
  

• 旧版MinGW可尝试--enable-stdcall-fixup链接选项：不过你使用的是较新的MinGW-W64 14.2.0，上面的-fno-indirect-call-ret已经足够生效，无需额外链接选项。

当然也可以写内联汇编硬编码call [Sleep]，但这种方式不通用，实际项目中没必要这么做。

2. GCC默认用mov+call组合的原因 #

主要和MinGW-W64的设计以及GCC的代码生成逻辑有关：

• POSIX兼容的历史遗留：MinGW-W64是在Windows上模拟POSIX环境的工具链，GCC的x86_64后端大量继承自Linux平台的实现。在Linux中，动态函数调用依赖PLT（过程链接表），而PLT的调用逻辑就是先把函数地址加载到寄存器再调用，这套逻辑被直接延续到了Windows平台的编译流程中。
• 分支预测与缓存优化：mov rax, [addr]; call rax这种方式在部分场景下更利于CPU分支预测器工作。寄存器间接调用的分支目标更容易被跟踪，尤其是多次调用同一个函数时，寄存器里的地址可以被缓存，减少重复内存访问的开销。
• 动态链接机制适配：MinGW-W64的.idata段处理逻辑和MSVC的.rdata不同，GCC用寄存器中转的方式，能更好适配自身的动态链接流程，确保在复杂的动态库依赖场景下调用稳定。

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