C 系统库中函数的ABI

我正在生成机器代码来调用现有系统库中的函数。大多数系统库都是用C编写的，所以我将以C为例，但这个问题可能适用于任何其他语言

如果我理解正确，C编译器可以自由选择函数的ABI/调用约定，只要它们保留语义。例如，他们可以选择将返回值的指针作为参数传递，以获得副本省略

这是否意味着没有人能够真正知道从库中调用函数的正确方法，即使它的C签名是已知的

在实践中这是一个真正的问题吗？或者可以安全地假设系统库中所有具有未损坏名称的函数始终使用系统的默认调用约定吗

对于系统库中具有非损坏名称的函数的ABI/调用约定，我还可以做哪些其他假设或考虑

C编译器可以自由选择函数的ABI/调用约定，只要它们保留语义

嗯，是和否。ABI通常由目标系统定义，在这种情况下，编译器必须保持一致。如果目标系统不存在ABI（通常在微控制器编程中），编译器可以随心所欲，基本上发明了ABI

这是否意味着没有人能够真正知道从库中调用函数的正确方法，即使它的C签名是已知的

不，除非你知道目标系统和调用约定，否则你不能。有些系统有几个“事实上”的标准，如x86 Windows

\uuuu cdecl

vs

\uu stdcall

请参阅

在实践中这是一个真正的问题吗

不在完全用C编写的程序中。但如果程序链接外部库（如Windows DLL），可能用其他语言编写，这将成为一个大问题。然后必须使用正确的调用约定，否则程序很快就会崩溃

当您尝试为给定系统混合汇编程序和C时，这也是一个非常重要的问题—C编译器将根据调用约定处理堆栈，但在汇编程序部分，您必须手动编写。这也会影响C代码，如果它是精心编写的，以适应汇编程序。然后选择便于使用的参数和返回类型

如果我正确理解这个答案，C编译器可以自由选择 函数的ABI/调用约定，只要它们保持 语义学。例如，他们可以选择为 返回值作为参数以获取副本省略

我不明白你是如何从你提到的答案中得出结论的。调用约定是函数的一个特征，因为它以编译形式出现。编译器可以在调用点执行各种各样的技巧，但更改或忽略函数实现的调用约定并不是其中之一。在可能的情况下，返回的结构值（答案的主题）的复制省略不依赖于任何此类内容

这是否意味着没有人能够真正知道什么是正确的方法 从库中调用函数，即使其C签名已知

是和否。函数签名本身并没有传达任何关于调用约定的信息（有一些警告；请参见下文），但是如果没有办法知道调用约定，库就无法工作。在实践中，通常情况下，调用约定（以及ABI整体）是基于每个平台进行标准化的

因此，例如，x86_64的Linux实现基本上都遵循相同的约定。所有针对该平台的工具链都使用该约定进行函数调用，并根据该约定提供要调用的函数。Win64编译器同样遵循适当的（不同的）约定

然而，Windows实际上是一个有趣的例子，因为从历史上看，它支持多种调用约定。在这种情况下，有一个默认约定，可以通过扩展关键字在函数声明中指定不同的约定。编译器根据函数声明知道要使用哪种约定

此外，在不关心互操作性的地方，编译器可以在力所能及的范围内做任何事情。因此，例如，在编译具有内部链接的函数时，原则上，它可以使用它想要的任何调用约定，因为它完全控制函数和所有调用方（忽略函数指针的可能影响）。这与编译器内联函数的能力并无本质区别。然而，实际上，我不希望编译器在这种情况下使用变量调用约定，我也不知道有哪种会这样做

在实践中这是一个真正的问题吗？还是可以安全地假设 系统库中具有未损坏名称的函数始终使用 系统的默认调用约定

名字弄乱与此无关。这是C++（通常）语义映射到系统级、源语言无关的对象文件格式的高级映射的一部分。 一般来说，可以安全地假设适当的函数声明在范围内（通常来自库的头文件），编译器将生成正确的调用。这是一个基本的互操作性特征，在实践中很少被违反。它不能被解释为一个普遍的保证，但在实践中，这不是你应该担心的事情

我还可以对该项目做出哪些其他假设或考虑 ABI/系统中具有非损坏名称的函数的调用约定 图书馆

我不确定你在想什么样的假设，我怀疑你把事情复杂化了。请确保包含该文件的相关库中的标题