x86 cdecl调用约定中，为何需清理栈？重置栈帧已回收空间时

维基百科中关于x86调用约定的页面展示了调用者清理栈约定的汇编代码示例，其中由调用者负责清理栈上的参数。

注：我移除了原注释并添加了自定义注释

C代码示例 #

int callee(int, int, int);

int caller(void)
{
    return callee(1, 2, 3) + 5;
}

对应的汇编代码 #

caller:
    push    ebp
    mov     ebp, esp

    push    3
    push    2
    push    1
    call    callee
    ; 此时已从callee()返回，结果存储在eax中

    add     esp, 12    ; 现在通过将esp加12（3个int占用的空间）清理栈
    add     eax, 5
    mov     esp, ebp   ; 此处将ebp的值赋给esp，即"esp = ebp"
                       ; 意味着即便我们将esp减去百万字节而非仅12，也不会有影响，因为我们直接给esp赋了新值
    pop     ebp
    ret

此前有类似问题讨论“为何必须清理栈”，核心答案都是栈空间有限需清理，但在这个场景里，3次push占用的内存会在mov esp, ebp重置栈帧时被“释放”，可供后续使用，那为什么还要特意执行add esp, 12来清理栈？

解答 #

这得从调用约定的规范性和实际场景的兼容性两个核心角度来说：

• 调用约定是硬性规则
  cdecl作为x86平台明确的调用约定，规定了“调用者负责清理栈参数”是必须遵守的标准。哪怕后续有mov esp, ebp重置栈帧的操作，add esp, 12是符合约定的标准实现。编译器生成代码时严格遵循约定，才能保证自己的代码和第三方库、其他模块的函数交互不出问题——毕竟不是所有函数调用后都会立刻重置栈帧，比如调用callee后如果还要push其他数据调用另一个函数，残留的参数会直接导致栈位置错误，引发程序崩溃。

• 保障调试时的栈帧完整性
  调试器依赖清晰的栈帧结构来回溯调用栈、查看局部变量和参数。如果跳过add esp, 12，虽然最终栈会被重置，但在调用函数后到重置栈帧前的这段时间里，栈上残留的参数会打乱栈帧结构，调试时无法正确解析当前栈状态，增加定位问题的难度。

• 避免复杂场景下的栈溢出
  这个例子里调用函数后马上重置了栈帧，但在更复杂的函数中——比如调用callee后还有循环push数据、多次调用其他函数的操作，不及时清理参数占用的栈空间会更快耗尽栈内存，触发栈溢出错误。遵循约定及时清理，能从根源上避免这类场景的风险。

• 兼容编译器优化
  现代编译器会做栈帧省略优化（比如跳过push ebp/mov ebp, esp），这时add esp, 12就成了唯一清理栈参数的方式。如果依赖mov esp, ebp来间接清理，在开启栈帧优化的场景下就会彻底出错，导致栈永远处于混乱状态。

总结下来，add esp, 12绝非多余操作，它是遵循调用约定的必要步骤，能保证代码的规范性、兼容性和可调试性，同时规避潜在的栈相关问题。

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