应用二进制接口(ABI)

ABI -应用二进制接口是关于运行时两个二进制部分之间的机器码通信，如应用程序，库，操作系统…ABI描述了如何将对象保存在内存中，如何调用函数(调用约定)，如何修改…

API和ABI的一个很好的例子是iOS生态系统从v5开始使用Swift语言。

Application layer - When you create an application using different languages. For example you can create application using Swift and Objective-C[Mixing Swift and Objective-C] Application - OS layer - runtime - Swift Standard Library and Swift Run Time Library[About] are parts of OS and they should not be included into each bundle(e.g. app, framework). It is the same as like Objective-C uses. Available from iOS v12.2 Library layer - Module Stability case - compile time - you will be able to import a framework which was built with another version of Swift's compiler. It means that it is safety to create a closed-source(pre-build) binary which will be consumed by a different version of compiler( .swiftinterface is used with .swiftmodule[About]) and you will not get Module compiled with _ cannot be imported by the _ compiler //or Compiled module was created by a newer version of the compiler Library layer - Library Evolution case Compile time - if a dependency was changed, a client has not to be recompiled. Runtime - a system library or a dynamic framework can be hot-swapped by a new one.

[API vs ABI] [Swift模块稳定性和库稳定性]

答:简单地说，ABI与API的一个共同之处是它是一个接口。可重用程序公开了一个稳定的接口(API)，可用于在另一个程序中重用该程序。

B. However, an ABI is an interface issued for some specific processor-platform for some specific language. All compiler-vendors desiring to target that platform for that same language will have to ensure that not only compiled code in form of relocatable object codes comply with the interface to be able to link and cross-link with each other but also executables comply with it to be able to run on the platform at all. So, ABI is much broader set of specifications/standard than a typical function API. It may include some API objects to be enforced upon the language-users by the compiler. The compiler-vendor will have to include support for the same in their distributions. Needless to say, the platform vendor is the rightful authority to issue ABIs for its platform. Both compiler vendors and ABIs need to comply with the corresponding language-standard (e.g. ISO standard for C++).

C.平台供应商对ABI的定义是:

“1。可执行文件为了在特定的执行环境中执行而必须遵守的规范。例如，Arm架构的Linux ABI。

独立生成的可重定位文件必须遵守的规范的一个特定方面，以便静态可链接和可执行。例如，Arm架构的c++ ABI, Arm架构的运行时ABI, Arm架构的C库ABI。”

D.举例;基于Itanium架构的c++通用ABI也由一个联盟发布。平台供应商自己的c++的abi在多大程度上符合它完全取决于平台供应商。

E.作为另一个例子。Arm架构的c++ ABI在这里。

F.前面已经说过，处理器体系结构的ABI将确保一个可重用程序和另一个重用它的程序之间的API适用于该处理器体系结构。

G. That brings us to service-oriented components (e.g. SOAP-based web services). They too require an API to exist between a SOAP-based web service and client program (could be an app, front-end or another web service) for the client program to reuse the web service.The API is described in terms of standardized protocols like WSDL (interface description) and SOAP(message format) and is language-neutral and platform-neutral. It is not targeted to any specific processor-platform and thus it is not "binary" like ABI. A client-program on any one platform type and written in any language can remotely reuse a web service written in any other language and hosted on an entirely different processor-platform. This is made possible by the fact that both WSDL and SOAP are text-based (XML) protocols. In case of RESTful web services, the transport protocol http--also a text-based protocol-- itself acts as the API (CRUD methods).

我也试图理解ABI, JesperE的回答很有帮助。

从一个非常简单的角度来看，我们可以尝试通过考虑二进制兼容性来理解ABI。

KDE wiki将库定义为二进制兼容的，“如果动态链接到库的前版本的程序继续与库的新版本一起运行，而不需要重新编译”。有关动态链接的更多信息，请参阅静态链接与动态链接

现在，让我们试着看看一个库需要二进制兼容性的最基本方面(假设库没有源代码更改):

相同/向后兼容的指令集架构(处理器指令、寄存器文件结构、堆栈组织、内存访问类型，以及处理器可以直接访问的基本数据类型的大小、布局和对齐) 相同调用约定 同名混淆约定(如果Fortran程序需要调用一些c++库函数，这可能是需要的)。

当然，还有许多其他细节，但这主要是ABI所涵盖的内容。

更具体地回答你的问题，由以上，我们可以推断:

ABI功能:二进制兼容性 现有实体:现有程序/库/操作系统 消费者:库，操作系统

希望这能有所帮助!

应用程序二进制接口(ABI)类似于API，但是调用者不能在源代码级别上访问该函数。只有二进制表示是可访问的/可用的。

abi可以在处理器体系结构级别或操作系统级别定义。 abi是编译器的代码生成器阶段要遵循的标准。该标准由操作系统或处理器决定。

功能:定义机制/标准，使函数调用独立于实现语言或特定的编译器/链接器/工具链。提供允许JNI或Python-C接口等的机制。

现有实体:机器代码形式的函数。

消费者:另一个函数(包括用另一种语言编写的、由另一种编译器编译或由另一种链接器链接的函数)。

功能:一组影响编译器、程序集编写者、链接器和操作系统的契约。契约规定了函数如何布局，参数在哪里传递，参数如何传递，函数返回如何工作。这些元组通常特定于(处理器体系结构，操作系统)元组。

现有实体:参数布局、函数语义、寄存器分配。例如，ARM架构有许多ABI (APCS, EABI, GNU-EABI，更不用说一堆历史案例)-使用混合ABI会导致你的代码在跨边界调用时无法工作。

使用者:编译器、程序集编写器、操作系统、CPU特定架构。

谁需要这些细节?编译器，程序集编写者，代码生成(或对齐要求)的链接器，操作系统(中断处理，系统调用接口)。如果您进行汇编编程，那么您将遵循ABI!

c++的名称破坏是一个特殊的情况——它是一个以连接器和动态连接器为中心的问题——如果名称破坏没有标准化，那么动态链接将无法工作。从今以后，c++ ABI就这么叫了，c++ ABI。这不是链接器级别的问题，而是代码生成的问题。一旦你有了一个c++二进制文件，如果不从源代码重新编译，就不可能使它与另一个c++ ABI兼容(名称混乱，异常处理)。

ELF是一种用于加载器和动态链接器的文件格式。ELF是二进制代码和数据的容器格式，它指定了一段代码的ABI。我不认为ELF是严格意义上的ABI，因为PE可执行文件不是ABI。

所有的abi都是特定于指令集的。ARM ABI在MSP430或x86_64处理器上没有意义。

Windows有几个abi -例如，fastcall和stdcall是两个常用的abi。系统调用ABI又不同了。

实际上你根本不需要ABI如果

你的程序没有函数，而且—— 你的程序是一个单独运行的可执行文件(即一个嵌入式系统)，它实际上是唯一在运行的东西，它不需要与其他任何东西对话。

过度简化的总结:

API:“这里是你可以调用的所有函数。” ABI:“这是调用函数的方法。”

ABI是编译器和链接器遵守的一组规则，以便编译您的程序，使其正常工作。ABIs涵盖多个主题:

Arguably the biggest and most important part of an ABI is the procedure call standard sometimes known as the "calling convention". Calling conventions standardize how "functions" are translated to assembly code. ABIs also dictate the how the names of exposed functions in libraries should be represented so that other code can call those libraries and know what arguments should be passed. This is called "name mangling". ABIs also dictate what type of data types can be used, how they must be aligned, and other low-level details.

更深入地了解调用约定，我认为它是ABI的核心:

机器本身没有“功能”的概念。当你用高级语言(如c)编写函数时，编译器会生成一行汇编代码，如_MyFunction1:。这是一个标签，它最终将被汇编程序解析为一个地址。这个标签标记了程序集代码中“函数”的“开始”。在高级代码中，当你“调用”这个函数时，你真正做的是导致CPU跳转到那个标签的地址并继续在那里执行。

在为跳转做准备时，编译器必须做一些重要的事情。调用约定就像一个清单，编译器遵循它来完成所有这些事情:

First, the compiler inserts a little bit of assembly code to save the current address, so that when your "function" is done, the CPU can jump back to the right place and continue executing. Next, the compiler generates assembly code to pass the arguments. Some calling conventions dictate that arguments should be put on the stack (in a particular order of course). Other conventions dictate that the arguments should be put in particular registers (depending on their data types of course). Still other conventions dictate that a specific combination of stack and registers should be used. Of course, if there was anything important in those registers before, those values are now overwritten and lost forever, so some calling conventions may dictate that the compiler should save some of those registers prior to putting the arguments in them. Now the compiler inserts a jump instruction telling the CPU to go to that label it made previously (_MyFunction1:). At this point, you can consider the CPU to be "in" your "function". At the end of the function, the compiler puts some assembly code that will make the CPU write the return value in the correct place. The calling convention will dictate whether the return value should be put into a particular register (depending on its type), or on the stack. Now it's time for clean-up. The calling convention will dictate where the compiler places the cleanup assembly code. Some conventions say that the caller must clean up the stack. This means that after the "function" is done and the CPU jumps back to where it was before, the very next code to be executed should be some very specific cleanup code. Other conventions say that the some particular parts of the cleanup code should be at the end of the "function" before the jump back.

有许多不同的abi /调用约定。主要有:

x86或x86-64 CPU(32位环境): CDECL STDCALL FASTCALL VECTORCALL THISCALL x86-64(64位环境): SYSTEMV MSNATIVE VECTORCALL ARM CPU(32位) AAPCS ARM处理器(64位) AAPCS64

这里有一个很棒的页面，它实际显示了为不同的abi编译时生成的程序集的差异。

另一件需要提及的事情是，ABI不仅仅与程序的可执行模块内部相关。链接器还使用它来确保程序正确调用库函数。您的计算机上运行着多个共享库，只要编译器知道它们各自使用的ABI，它就可以正确地从它们调用函数，而不会破坏堆栈。

编译器理解如何调用库函数是非常重要的。在一个托管平台上(也就是说，一个OS加载程序的平台)，如果不调用内核，您的程序甚至不能闪烁。