模块内部本地函数调用遵循ABI的目的是什么？其执行约束体现在哪里？

无外部引用函数的ABI遵循问题解答 #

首先纠正一个常见误解：平台官方约定的ABI规则本质是跨模块/编译单元的公共调用契约，仅强制约束具备外部链接属性、可能被其他独立编译的代码调用的函数，本身不限制仅当前编译单元可见的私有函数的实现逻辑。你观察到的编译器对这类私有函数违反标准ABI的情况，属于正常的优化行为，不是违规。

为什么多数时候无外部引用的函数仍会默认遵循ABI？ #

主要有几个现实限制：

• 独立编译的不确定性：如果没有开启链接时优化（LTO），每个编译单元是单独编译的。编译器在处理一个static函数时，无法100%确定它会不会在当前编译单元内被取址赋值给函数指针——如果后续存在通过函数指针的调用，而编译器给该函数自定义了调用约定，就会出现调用栈不匹配的崩溃。除非编译器能完整追踪到该函数的所有调用点，否则不会随意修改调用约定。
• 调试与栈回溯的兼容性：所有主流调试器、栈分析工具都是按照平台标准ABI来解析栈帧、提取参数、生成调用链的。如果私有函数完全自定义调用约定，调试时会出现栈回溯失败、参数无法识别的问题，大幅提升排查成本。
• 异常展开的依赖：C++异常、Windows结构化异常（SEH）等机制的栈展开逻辑，完全依赖标准ABI定义的栈帧结构完成调用栈遍历。随意修改调用约定会导致异常抛出时无法正确清理栈资源，直接触发程序崩溃。
• 编译器实现成本：为每个私有函数单独设计专属调用约定，会大幅提升后端代码生成、寄存器分配的逻辑复杂度，对于非热点函数来说优化收益极低，编译器默认不会做这种高成本低收益的处理。

违反约定会有什么问题？ #

如果满足以下所有条件，违反标准ABI完全不会产生任何问题，高优化等级下编译器也确实会主动做这类优化：

1. 该函数没有外部链接属性，仅当前编译单元可见
2. 编译器可以完整追踪到该函数的所有调用点，没有通过函数指针的间接调用
3. 不需要依赖通用调试工具分析该函数的运行状态
4. 函数内不会抛出异常，也不属于异常展开的栈路径中的节点

比如GCC开启-O2以上优化、加上-fipa-ra参数时，就会自动为符合条件的私有函数调整寄存器使用规则，不需要完全遵循x86/x64的标准调用约定。

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