MSVC Debug编译下x86_64中超出Shadow Space的额外栈空间分配疑问

原始C代码 #

#include <stdlib.h>

int func() {
    return 0xbeef;
}

int main() {
    func();
    return 0xf00d;
}

MSVC反汇编代码 #

int func() {
0000000140001002  sub         rsp,40h  
0000000140001006  mov         rbp,rsp  
    return 0xbeef;
0000000140001009  mov         eax,0BEEFh  
}
000000014000100E  lea         rsp,[rbp+40h]  
0000000140001012  pop         rbp  
0000000140001013  ret  

int main() {
0000000140001020  push        rbp  
0000000140001022  sub         rsp,60h  
0000000140001026  lea         rbp,[rsp+20h]  
    func();
000000014000102B  call        func (0140001000h)  
0000000140001030  nop  
    return 0xf00d;
0000000140001031  mov         eax,0F00Dh  
}
0000000140001036  lea         rsp,[rbp+40h]  
000000014000103A  pop         rbp  
000000014000103B  ret  

疑问背景 #

根据x64 ABI规范，调用其他函数的函数需预留32字节栈空间作为Shadow Space，用于存放RCX、RDX、R8、R9寄存器中的被调用函数前四个整型参数值，即使被调用函数参数少于四个，调用者也必须分配该空间。

问题 #

既然代码中没有局部变量或使用alloca()分配栈空间，调用main()的函数为何为main()分配96字节而非32字节？同样，main()为何为func()分配64字节而非32字节？

解答 #

你的Shadow Space理解完全正确，实际栈空间超出预期主要是以下几个原因：

1. x64栈的强制对齐要求 #

x64 ABI规定，call指令执行前栈指针rsp必须保持16字节对齐。call指令会将8字节的返回地址压入栈，所以进入函数后rsp会处于8字节偏移的不对齐状态，函数开头必须调整rsp重新回到16字节对齐的位置。调整的栈空间大小必须是16的倍数，这就导致实际分配的空间可能会比最小需求多，用于填充对齐。

2. Debug模式的默认行为 #

你看到的是Debug编译的结果，MSVC在Debug模式下会：

• 禁用栈空间优化，分配比实际需求更大的固定栈空间，方便调试时查看栈帧、插入栈保护机制；
• 强制启用帧指针（RBP），维护完整的栈帧结构，这会额外占用栈空间；
• 不会精准计算最小所需空间，而是采用统一的栈空间分配策略，比如为无局部变量的函数默认分配64字节栈空间。

3. CRT启动代码的额外预留 #

main作为程序入口，调用它的是CRT（C运行时）的启动函数。启动函数会为main分配额外的栈空间，用于传递命令行参数、环境变量等数据（即使你的代码没有显式使用这些数据，CRT仍然会预留），这部分空间也包含在你看到的96字节里。

验证方式 #

如果切换到Release模式编译，编译器会开启优化：

• func可能不需要额外分配栈空间（直接返回值，无函数调用）；
• main只会分配刚好满足Shadow Space和对齐要求的栈空间，会接近32字节的最小需求。

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