违反ABI调用约定的后果及自定义调用约定相关技术问询

你的核心理解大方向正确，但存在几个容易被忽略的边界场景。

只要你能完全掌控调用方、被调用方两端的代码生成逻辑，内部函数互调确实可以自由定义调用约定：不管是参数传递用寄存器还是栈、参数排列顺序、调用者/被调用者谁负责平衡栈、返回值存储位置、哪些寄存器归调用者保存哪些归被调用者保存，你完全可以针对L语言的特性做定制优化，比如给高频小函数传更多寄存器参数、给带垃圾回收/异常机制的语言定制特殊栈帧结构方便栈扫描。
这本身是编译器开发的常规操作，不是什么野路子：Go在1.17版本之前就一直使用自研的内部调用约定，没有对齐平台System V ABI，目的就是压缩函数调用开销；OCaml、GHC（Haskell编译器）的运行时也长期使用自定义的内部调用约定。

但必须遵守原生ABI的场景不止系统调用、外部函数调用两类，以下场景也必须严格匹配平台S的ABI规则，否则必然出问题：

• 系统触发的回调函数：包括*nix平台的信号处理函数、Windows平台的SEH异常处理回调、动态链接库的初始化/析构入口、线程启动入口，这些代码是被内核或系统原生逻辑直接调用的，没有做调用约定转换的空间
• 需要对接系统原生工具的场景：如果希望gdb、perf、WinDbg这类系统级调试、性能分析工具能正常解析你的程序调用栈，栈帧的布局、返回地址的存储规则至少要兼容原生ABI的栈展开要求，否则工具会直接把调用栈解析成乱码

除了已知的外部函数互操作问题，自定义调用约定还会带来这些实打实的成本：

• 工具链复用难度陡增：你没法直接复用平台原生的栈展开、异常处理、栈回溯相关的库函数，所有和调用栈相关的逻辑——包括垃圾回收的栈扫描、异常抛出时的栈展开、panic时的调用栈打印——都要从零实现，维护成本很高
• 边界转换开销：如果你的代码需要把内部函数作为回调传给外部库，必须额外写一层thunk代码做调用约定转换（包括调整参数位置、补全寄存器保存/恢复逻辑、平衡栈），高频回调场景下这层转换会带来明显的性能损耗；一旦thunk代码漏写了某个寄存器的保存规则，会出现极其难排查的偶发bug
• 调试成本极高：除了系统原生调试工具无法识别你的自定义栈帧，你自己为L语言开发调试工具时，也要单独适配自定义栈帧的解析逻辑；如果出现调用约定相关的bug（比如参数传错位、寄存器被意外覆盖），排查难度会远高于对齐原生ABI的实现
• 架构移植成本上升：每移植到一个新的CPU架构，你都要重新实现全套自定义调用约定的逻辑；如果内部调用约定对齐原生ABI，这部分的大量逻辑可以直接复用目标架构的现成实现。

后果的严重程度完全取决于你破坏了ABI的哪部分规则，常见情况包括：

• 逻辑错误：如果传参位置、返回值存储位置不符合ABI约定，会直接导致外部函数读到错误的参数、返回值被篡改，出现不符合预期的业务逻辑
• 随机偶发bug：如果违反了寄存器保存规则——比如原生ABI规定rbx/rbp/r12-r15这类寄存器是被调用者保存的，你在调用外部函数的过程中随意修改了这些寄存器且没有恢复，等执行流返回原生代码后，会出现野指针、循环变量异常、内存越界这类完全跳脱于你代码逻辑的随机问题，这类bug复现概率低，定位难度极大
• 直接崩溃：如果破坏了栈平衡规则、篡改了栈上的返回地址，会导致程序执行流跳转到非法内存地址，直接触发段错误崩溃；如果是在系统调用路径上破坏了内核期望的栈结构，甚至可能触发系统级崩溃
• 隐蔽的计算错误：很多平台的ABI对浮点寄存器、SIMD向量寄存器的保存规则有单独约定，违反这部分规则通常不会直接崩溃，但会出现浮点数计算结果随机错误、SIMD指令执行异常这类极难定位的问题。

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