系统库中函数的 ABI

如何解决系统库中函数的 ABI

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

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

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

这在实践中是一个真正的问题吗？或者假设所有来自系统库的名称未混淆的函数总是使用系统的默认调用约定是否安全？

对于系统库中具有非错位名称的函数的 ABI/调用约定，我还能做出哪些其他假设或考虑？

解决方法

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

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

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

不，除非你知道目标系统和调用约定，否则你不能。一些系统有几个“事实上的”标准，例如 x86 Windows __cdecl vs __stdcall 参见 https://en.wikipedia.org/wiki/X86_calling_conventions

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

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

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

,

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

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

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

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

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

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

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

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

名称修改与此无关。这是 C++（通常）语义到系统级、独立于源语言的目标文件格式的更高级别映射的一部分。

一般来说，可以安全地假设适当的函数声明在范围内（通常来自库的头文件），编译器将生成正确的调用。这是在实践中很少违反的基本互操作性特性。不能将其解释为普遍保证，但在实践中，您不必担心。

我还能做出哪些其他假设或考虑？ 系统中具有非修饰名称的函数的 ABI/调用约定 图书馆？

我不确定您的想法是什么类型的假设，我怀疑您把事情想得太复杂了。您确保包含声明要调用的函数的相关库中的头文件。这样做后，您依靠编译器来生成正确的调用。