系统库中函数的 ABI
ABI of functions in system libraries
我正在生成机器代码来调用现有系统库中的函数。大多数系统库都是用 C 编写的，所以我将以 C 为例，但这个问题可能适用于任何其他语言。
如果我 理解正确，C 编译器可以自由选择函数的 ABI/calling 约定，只要它们保留语义即可。例如，他们可以选择将返回值的指针作为参数传递，以获得复制省略。
这是否意味着没有人能够真正知道从库中调用函数的正确方法是什么，即使它的 C 签名是已知的？
这在实践中是否真的值得关注？还是假设系统库中所有名称未损坏的函数始终使用系统的默认调用约定是否安全？
关于系统库中具有未损坏名称的函数的 ABI/calling 约定，我可以做出哪些其他假设或考虑？
C compilers are free to choose the ABI/calling convention of a function as long as they preserve the semantics.
好吧，是的，也不是。 ABI 通常由目标系统定义，在这种情况下，编译器必须符合要求。如果目标系统不存在 ABI（在微控制器编程中通常是这种情况），编译器可以随心所欲，基本上是发明 ABI。
Does this mean that no one can ever truly know what's the right way to call a function from a library, even if its C signature is known?
不，你不能，除非你知道目标系统和调用约定。一些系统有几个“事实上的”标准，例如 x86 Windows __cdecl vs __stdcall 参见 https://en.wikipedia.org/wiki/X86_calling_conventions
Is this a real concern in practice?
不在完全用 C 编写的程序中。但是如果程序链接外部库（例如 Windows DLL，可能用其他语言编写），这将成为一个大问题。那么你必须使用正确的调用约定，否则程序很快就会崩溃。
每当您尝试为给定系统混合使用汇编程序和 C 时，这也是一个非常实际的问题 - C 编译器将根据调用约定处理堆栈，但在汇编程序部分，您必须手动编写。这也会影响 C 代码，如果它被小心地编写以适合汇编程序的话。然后，您可以选择便于使用的参数和 return 类型。
If I understand this answer correctly, C compilers are free to choose
the ABI/calling convention of a function as long as they preserve the
semantics. For instance they can choose to pass a pointer for the
returned value as an argument to obtain copy-elision.
我看不出你是如何从你引用的答案中得出结论的。调用约定是函数的一个特征，因为它以编译形式出现。编译器可以在调用点执行各种技巧，但更改或忽略函数实现的调用约定不是其中之一。在可能的情况下，返回的结构值（该答案的主题）的复制省略不依赖于任何此类事物。
Does this mean that no one can ever truly know what's the right way to
call a function from a library, even if its C signature is known?
是也不是。函数签名本身并没有传达任何关于调用约定的信息（有一些注意事项；见下文），但是如果没有办法知道调用约定，库就无法工作。在实践中，调用约定（以及整个 ABI）通常是在 per-platform 基础上标准化的。
因此，例如，Linux x86_64 的实现基本上都遵循相同的约定。针对该平台的所有工具链都使用该约定进行函数调用，并提供根据它调用的函数。 Win64 的编译器同样遵循适当的（不同的）约定。
Windows 实际上是一个有趣的案例，但是，因为从历史上看，它支持 多个 调用约定。在它的例子中，有一个默认约定，可以通过扩展关键字在函数声明中指定不同的约定。编译器根据函数声明知道使用哪种约定。
此外，在不关心互操作性的地方，编译器可以做任何力所能及的事情。因此，例如，在编译具有内部链接的函数时，原则上它可以使用它想要的任何调用约定，因为它完全控制函数和所有调用者（忽略函数指针的可能影响）。这与编译器内联函数的能力没有本质区别。然而，作为一个实际问题，我不希望编译器在这种情况下使用变体调用约定，而且我不知道有什么会这样做。
Is this a real concern in practice? Or is it safe to assume that all
the functions with non-mangled names from system libraries always use
the system's default calling convention?
名称修改与此无关。这是 C++（通常）语义到 system-level、source-language-independent object-file 格式的 higher-level 映射的一部分。
一般来说，可以安全地假设适当的函数声明在范围内（通常来自库的 header 文件），编译器将生成正确的调用。这是一个基本的互操作性特征，在实践中很少被违反。它不能解释为普遍保证，但在实践中，这不是您应该担心的事情。
What other assumptions or considerations can I make about the
ABI/calling convention of functions with non-mangled names in system
libraries?
我不确定你的想法是什么，我怀疑你把事情复杂化了。您确保包含来自相关库的 header(s)，这些库声明了您要调用的函数。这样做之后，您依靠编译器生成正确的调用。
我正在生成机器代码来调用现有系统库中的函数。大多数系统库都是用 C 编写的，所以我将以 C 为例，但这个问题可能适用于任何其他语言。
如果我
这是否意味着没有人能够真正知道从库中调用函数的正确方法是什么，即使它的 C 签名是已知的？
这在实践中是否真的值得关注？还是假设系统库中所有名称未损坏的函数始终使用系统的默认调用约定是否安全？
关于系统库中具有未损坏名称的函数的 ABI/calling 约定，我可以做出哪些其他假设或考虑？
C compilers are free to choose the ABI/calling convention of a function as long as they preserve the semantics.
好吧，是的，也不是。 ABI 通常由目标系统定义，在这种情况下，编译器必须符合要求。如果目标系统不存在 ABI（在微控制器编程中通常是这种情况），编译器可以随心所欲，基本上是发明 ABI。
Does this mean that no one can ever truly know what's the right way to call a function from a library, even if its C signature is known?
不，你不能，除非你知道目标系统和调用约定。一些系统有几个“事实上的”标准，例如 x86 Windows __cdecl vs __stdcall 参见 https://en.wikipedia.org/wiki/X86_calling_conventions
Is this a real concern in practice?
不在完全用 C 编写的程序中。但是如果程序链接外部库（例如 Windows DLL，可能用其他语言编写），这将成为一个大问题。那么你必须使用正确的调用约定，否则程序很快就会崩溃。
每当您尝试为给定系统混合使用汇编程序和 C 时，这也是一个非常实际的问题 - C 编译器将根据调用约定处理堆栈，但在汇编程序部分，您必须手动编写。这也会影响 C 代码，如果它被小心地编写以适合汇编程序的话。然后，您可以选择便于使用的参数和 return 类型。
If I understand this answer correctly, C compilers are free to choose the ABI/calling convention of a function as long as they preserve the semantics. For instance they can choose to pass a pointer for the returned value as an argument to obtain copy-elision.
我看不出你是如何从你引用的答案中得出结论的。调用约定是函数的一个特征，因为它以编译形式出现。编译器可以在调用点执行各种技巧，但更改或忽略函数实现的调用约定不是其中之一。在可能的情况下，返回的结构值（该答案的主题）的复制省略不依赖于任何此类事物。
Does this mean that no one can ever truly know what's the right way to call a function from a library, even if its C signature is known?
是也不是。函数签名本身并没有传达任何关于调用约定的信息（有一些注意事项；见下文），但是如果没有办法知道调用约定，库就无法工作。在实践中，调用约定（以及整个 ABI）通常是在 per-platform 基础上标准化的。
因此，例如，Linux x86_64 的实现基本上都遵循相同的约定。针对该平台的所有工具链都使用该约定进行函数调用，并提供根据它调用的函数。 Win64 的编译器同样遵循适当的（不同的）约定。
Windows 实际上是一个有趣的案例，但是，因为从历史上看，它支持 多个 调用约定。在它的例子中，有一个默认约定，可以通过扩展关键字在函数声明中指定不同的约定。编译器根据函数声明知道使用哪种约定。
此外，在不关心互操作性的地方，编译器可以做任何力所能及的事情。因此，例如，在编译具有内部链接的函数时，原则上它可以使用它想要的任何调用约定，因为它完全控制函数和所有调用者（忽略函数指针的可能影响）。这与编译器内联函数的能力没有本质区别。然而，作为一个实际问题，我不希望编译器在这种情况下使用变体调用约定，而且我不知道有什么会这样做。
Is this a real concern in practice? Or is it safe to assume that all the functions with non-mangled names from system libraries always use the system's default calling convention?
名称修改与此无关。这是 C++（通常）语义到 system-level、source-language-independent object-file 格式的 higher-level 映射的一部分。
一般来说，可以安全地假设适当的函数声明在范围内（通常来自库的 header 文件），编译器将生成正确的调用。这是一个基本的互操作性特征，在实践中很少被违反。它不能解释为普遍保证，但在实践中，这不是您应该担心的事情。
What other assumptions or considerations can I make about the ABI/calling convention of functions with non-mangled names in system libraries?
我不确定你的想法是什么，我怀疑你把事情复杂化了。您确保包含来自相关库的 header(s)，这些库声明了您要调用的函数。这样做之后，您依靠编译器生成正确的调用。