共计 1120 个字符，预计需要花费 3 分钟才能阅读完成。
从段错误开始的调用约定探索
上周调试一个跨 DLL 的 __cdecl 函数调用时，GDB 突然报 Segmentation fault。反汇编看到调用方用sub esp, 0x10 分配栈空间，而被调用方却用 ret 0x8 清理参数——典型的调用约定不匹配。这种问题在混合编程时尤其常见，今天我们就系统梳理 C ++ 的函数调用约定。
主流调用约定对比
1. __cdecl (C Declaration)
- 特点：调用方清理参数栈，支持可变参数
- 栈帧结构（x86）：
; 调用前 push arg3 push arg2 push arg1 ; 参数从右向左压栈 call func add esp, 12 ; 调用方清理栈 ; 被调函数内 push ebp mov ebp, esp ; ... 函数体 ... leave ret ; 无操作数
2. __stdcall (Standard Call)
- 特点：被调用方清理参数，WinAPI 标准
- x64 变化：前 4 个参数通过 RCX/RDX/R8/R9 传递
3. __fastcall
- x86：前两个参数通过 ECX/EDX 传递
- x64：默认调用约定（实际与__stdcall 合并）
跨模块调用实战
DLL 导出正确姿势
// 头文件声明
#ifdef BUILD_DLL
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
// 确保调用约定一致
API int __stdcall Calculate(int a, int b);强制导出符号（避免 name mangling）
#pragma comment(linker, "/EXPORT:Calculate=_Calculate@8")反汇编验证技巧
使用 objdump 验证调用约定：
objdump -d -M intel mylib.dll | grep -A 10 "Calculate"预期看到 ret 8 对应__stdcall 的栈清理行为。
性能基准测试
| 调用约定 | 调用耗时(ns) | 代码体积(bytes) |
|---|---|---|
| __cdecl | 15.2 | 84 |
| __stdcall | 14.7 | 76 |
| __fastcall | 12.1 | 65 |
（测试环境：i7-9700K，GCC 9.3，-O2 优化）
生产环境陷阱
1. 可变参数陷阱
// 必须使用__cdecl
int printf(const char* format, ...);2. 成员函数指针
- 需要
this指针隐式传递（ECX/RCX 寄存器） - 不同编译器实现可能不同
3. SEH 异常处理
- __stdcall 与结构化异常处理存在交互问题
- x64 下需确保
.pdata段正确配置
思考题延伸
当通过 Rust FFI 调用 C ++ 时：
- 如何保证
extern "C"函数的调用约定一致？ - 虚函数表布局差异如何解决？
- 异常能否跨语言边界传递？
下次我们将深入探讨这些 ABI 兼容性问题。
正文完
