共计 1552 个字符，预计需要花费 4 分钟才能阅读完成。
从段错误开始的探索
最近在调试一个跨 DLL 调用的崩溃问题时，GDB 给出了这样的错误信息：
Program received signal SIGSEGV, Segmentation fault.
0x00007ff6456a1023 in ?? ()查看反汇编后发现，调用方和被调用方使用了不同的 函数调用约定，导致栈指针错乱。这个案例让我意识到，理解调用约定对 C ++ 开发多么重要。
主流调用约定对比
x86 架构下的三种经典约定
- __cdecl（C Declaration）
- 调用方负责清理栈
- 支持可变参数
-
函数名前加下划线（如
_func） -
__stdcall（Standard Call）
- 被调用方清理栈
- 不支持可变参数
-
函数名前加下划线，后跟 @和参数字节数（如
_func@8） -
__fastcall
- 前两个参数通过 ECX 和 EDX 寄存器传递
- 剩余参数通过栈传递
- 函数名以 @开头，后跟 @和参数字节数（如
@func@8）
x64 架构的统一约定
x64 架构下，Windows 和 Linux 采用了不同的方案：
- Windows x64 调用约定：
- 前 4 个参数通过 RCX、RDX、R8、R9 传递
- 调用方预留 32 字节 影子空间
-
调用方负责清理栈
-
System V AMD64 ABI：
- 前 6 个参数通过 RDI、RSI、RDX、RCX、R8、R9 传递
- 有 128 字节red zone
跨模块调用实战
正确的 DLL 导出方法
// 头文件声明
#ifdef BUILD_DLL
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
extern "C" API int __stdcall Calculate(int a, int b);
// 使用 pragma 确保名称修饰正确
#pragma comment(linker, "/EXPORT:Calculate=_Calculate@8")反汇编验证技巧
使用 objdump 查看调用约定：
objdump -d libexample.so | grep -A 10 "<Calculate>:"典型 x86 __stdcall 函数序言：
; x86 assembly
push ebp
mov ebp, esp
sub esp, 0x10 ; 分配局部变量空间
; ... 函数体 ...
leave
ret 8 ; 清理 8 字节参数性能基准测试
| 调用约定 | 调用开销(cycles) | 代码大小(bytes) |
|---|---|---|
| __cdecl | 18 | 25 |
| __stdcall | 16 | 23 |
| __fastcall | 12 | 20 |
| x64 Windows | 8 | 15 |
生产环境陷阱
可变参数函数的坑
// 错误示例：printf 必须用__cdecl
void __stdcall Log(const char* fmt, ...); // 会导致栈不平衡成员函数指针的特殊性
成员函数指针在 x86 下占用 12 字节（包含调整指针）：
typedef void (__thiscall* ClassFuncPtr)(int);SEH 异常处理问题
结构化异常处理（SEH）依赖特定的栈帧布局，混合使用不同调用约定会导致异常处理失败。
多平台适配示例
#ifdef _WIN32
# ifdef _M_IX86
# define CALL __stdcall
# else
# define CALL
# endif
#else
# define CALL
#endif
extern "C" void CALL PlatformAgnosticFunc();扩展思考：Rust FFI 兼容性
当 Rust 调用 C ++ 时，需要特别注意：
1. 使用 extern "C" 确保符号命名规则一致
2. 通过 #[repr(C)] 控制结构体布局
3. 显式指定调用约定（如#[link(name="lib", kind="static")]）
理解调用约定不仅是调试栈问题的关键，更是进行系统级编程的基础技能。你在项目中还遇到过哪些与 ABI 相关的问题？欢迎在评论区分享你的经验。
正文完
