调用方和被调用方之间的ABI需要一致，以确保调用成功。堆栈使用，寄存器使用，程序结束堆栈弹出。所有这些都是ABI中最重要的部分。

让我至少回答你问题的一部分。通过一个例子说明Linux ABI如何影响系统调用，以及它为什么有用。

A systemcall is a way for a userspace program to ask the kernelspace for something. It works by putting the numeric code for the call and the argument in a certain register and triggering an interrupt. Than a switch occurs to kernelspace and the kernel looks up the numeric code and the argument, handles the request, puts the result back into a register and triggers a switch back to userspace. This is needed for example when the application wants to allocate memory or open a file (syscalls "brk" and "open").

现在系统调用有简短的名称“brk”等和相应的操作码，这些在系统特定的头文件中定义。只要这些操作码保持不变，您就可以使用不同更新的内核运行相同的已编译用户域程序，而无需重新编译。这样就有了预编译二进制文件使用的接口，因此就有了ABI。

如果您了解汇编以及操作系统级别的工作方式，那么您就符合特定的ABI。ABI控制参数的传递方式、返回值放置的位置等。对于许多平台来说，只有一种ABI可供选择，在这些情况下，ABI只是“事情如何工作”。

然而，ABI也控制着c++中类/对象的布局。如果您希望能够跨模块边界传递对象引用，或者如果您希望混合使用不同编译器编译的代码，这是必要的。

此外，如果您有一个可以执行32位二进制文件的64位操作系统，那么32位和64位代码将有不同的abi。

通常，链接到相同可执行文件中的任何代码都必须符合相同的ABI。如果希望在使用不同abi的代码之间进行通信，则必须使用某种形式的RPC或序列化协议。

我认为你过于努力地将不同类型的界面挤进一个固定的特征集。例如，一个界面不一定要分成消费者和生产者。接口只是两个实体交互的约定。

abi可以(部分地)与isa无关。有些方面(如调用约定)依赖于ISA，而其他方面(如c++类布局)则不依赖于ISA。

定义良好的ABI对于编写编译器的人来说非常重要。如果没有定义良好的ABI，就不可能生成可互操作的代码。

编辑:需要澄清的一些注释:

ABI中的“二进制”并不排除字符串或文本的使用。如果您想要链接一个导出c++类的DLL，则必须对其中的方法和类型签名进行编码。这就是c++名称破坏的用武之地。 您从未提供ABI的原因是绝大多数程序员都不会这样做。ABI是由设计平台(即操作系统)的人提供的，很少有程序员有特权设计一个广泛使用的ABI。

为了调用共享库中的代码，或者在编译单元之间调用代码，object文件需要包含调用的标签。c++修改了方法标签的名称，以加强数据隐藏并允许重载方法。这就是为什么您不能混合来自不同c++编译器的文件，除非它们显式地支持相同的ABI。

简而言之，从哲学上讲，只有某种类型的东西才能相处得很好，而ABI可以被看作是一种软件东西一起工作的东西。

理解“ABI”的一个简单方法是将其与“API”进行比较。

您已经熟悉了API的概念。如果你想使用某些库或操作系统的特性，你将根据API进行编程。API由数据类型/结构、常量、函数等组成，您可以在代码中使用它们来访问外部组件的功能。

An ABI is very similar. Think of it as the compiled version of an API (or as an API on the machine-language level). When you write source code, you access the library through an API. Once the code is compiled, your application accesses the binary data in the library through the ABI. The ABI defines the structures and methods that your compiled application will use to access the external library (just like the API did), only on a lower level. Your API defines the order in which you pass arguments to a function. Your ABI defines the mechanics of how these arguments are passed (registers, stack, etc.). Your API defines which functions are part of your library. Your ABI defines how your code is stored inside the library file, so that any program using your library can locate the desired function and execute it.

ABIs are important when it comes to applications that use external libraries. Libraries are full of code and other resources, but your program has to know how to locate what it needs inside the library file. Your ABI defines how the contents of a library are stored inside the file, and your program uses the ABI to search through the file and find what it needs. If everything in your system conforms to the same ABI, then any program is able to work with any library file, no matter who created them. Linux and Windows use different ABIs, so a Windows program won't know how to access a library compiled for Linux.

有时，ABI更改是不可避免的。当这种情况发生时，任何使用该库的程序都将无法工作，除非它们被重新编译以使用新版本的库。如果ABI改变了，但API没有改变，那么新旧库版本有时被称为“源代码兼容”。这意味着，虽然为一个库版本编译的程序不能与另一个库版本一起工作，但为一个库版本编写的源代码如果重新编译，则可以与另一个库版本一起工作。

For this reason, developers tend to try to keep their ABI stable (to minimize disruption). Keeping an ABI stable means not changing function interfaces (return type and number, types, and order of arguments), definitions of data types or data structures, defined constants, etc. New functions and data types can be added, but existing ones must stay the same. If, for instance, your library uses 32-bit integers to indicate the offset of a function and you switch to 64-bit integers, then already-compiled code that uses that library will not be accessing that field (or any following it) correctly. Accessing data structure members gets converted into memory addresses and offsets during compilation and if the data structure changes, then these offsets will not point to what the code is expecting them to point to and the results are unpredictable at best.

除非您正在进行非常低级的系统设计工作，否则您不必显式地提供ABI。它也不是特定于语言的，因为(例如)C应用程序和Pascal应用程序在编译后可以使用相同的ABI。

Edit: Regarding your question about the chapters regarding the ELF file format in the SysV ABI docs: The reason this information is included is because the ELF format defines the interface between operating system and application. When you tell the OS to run a program, it expects the program to be formatted in a certain way and (for example) expects the first section of the binary to be an ELF header containing certain information at specific memory offsets. This is how the application communicates important information about itself to the operating system. If you build a program in a non-ELF binary format (such as a.out or PE), then an OS that expects ELF-formatted applications will not be able to interpret the binary file or run the application. This is one big reason why Windows apps cannot be run directly on a Linux machine (or vice versa) without being either re-compiled or run inside some type of emulation layer that can translate from one binary format to another.

IIRC, Windows目前使用可移植可执行文件(PE)格式。在维基百科页面的“外部链接”部分有关于PE格式的更多信息的链接。

Also, regarding your note about C++ name mangling: When locating a function in a library file, the function is typically looked up by name. C++ allows you to overload function names, so name alone is not sufficient to identify a function. C++ compilers have their own ways of dealing with this internally, called name mangling. An ABI can define a standard way of encoding the name of a function so that programs built with a different language or compiler can locate what they need. When you use extern "c" in a C++ program, you're instructing the compiler to use a standardized way of recording names that's understandable by other software.

应用程序二进制接口(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)

功能:

从程序员的模型到底层系统的域数据的转换 类型，大小，对齐，调用约定，它控制如何 函数的参数被传递并返回检索到的值;的 系统调用编号以及应用程序应该如何进行系统调用 到操作系统;高级语言编译器的名称 破坏方案、异常传播和调用约定 在同一平台上的编译器之间，但不需要 跨平台兼容性……

现有的实体:

直接参与程序执行的逻辑块:ALU， 通用寄存器，用于内存/ I/O映射的寄存器，等等…

消费者:

语言处理器，链接器，汇编器…

任何必须确保构建工具链作为一个整体工作的人都需要这些。如果你用汇编语言写一个模块，用Python写另一个模块，而不是你自己的引导加载程序想要使用操作系统，那么你的“应用程序”模块是跨“二进制”边界工作的，需要这种“接口”的协议。

c++命名混乱，因为应用程序中可能需要链接来自不同高级语言的目标文件。考虑使用GCC标准库对Visual c++构建的Windows进行系统调用。

ELF是用于解释的来自对象文件的链接器的一种可能期望，尽管JVM可能有其他想法。

对于一个Windows RT商店应用程序，如果你真的想让一些构建工具链一起工作，尝试搜索ARM ABI。

区分ABI和API的最好方法是了解它的用途和原因:

对于x86-64，通常有一个ABI(对于x86 32位，有另一组ABI):

http://www.x86-64.org/documentation/abi.pdf

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/140-x86-64_Function_Calling_Conventions/x86_64.html

http://people.freebsd.org/~obrien/amd64-elf-abi.pdf

Linux + FreeBSD + MacOSX紧随其后，略有变化。Windows x64有自己的ABI:

http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/

Knowing the ABI and assuming other compiler follows it as well, then the binaries theoretically know how to call each other (libraries API in particular) and pass parameters over the stack or by registers etc. Or what registers will be changed upon calling the functions etc. Essentially these knowledge will help software to integrate with one another. Knowing the order of the registers / stack layout I can easily piece together different software written in assemblies together without much problem.

但是API是不同的:

它是一个定义了参数的高级函数名，这样如果不同的软件使用这些API构建，就可以相互调用。但是必须遵守SAME ABI的附加要求。

例如，Windows曾经是POSIX API兼容的:

https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

https://en.wikipedia.org/wiki/POSIX

Linux也是POSIX兼容的。但是二进制文件不能被移动并立即运行。但是因为它们在POSIX兼容的API中使用了相同的NAMES，所以您可以在C语言中使用相同的软件，在不同的操作系统中重新编译它，并立即让它运行起来。

API是为了简化软件集成-预编译阶段。所以在编译之后，如果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加载程序的平台)，如果不调用内核，您的程序甚至不能闪烁。

总结

对于定义ABI(应用程序二进制接口)的确切层有各种各样的解释和强烈的意见。

在我看来，ABI是对特定API的给定/平台的主观约定。ABI是对于特定API“不会改变”的约定的“剩余”部分，或者由运行时环境解决:执行器、工具、链接器、编译器、jvm和OS。

定义接口:ABI, API

如果你想使用像joda-time这样的库，你必须声明一个依赖joda-time-<major>.<minor>.<patch>.jar。标准库遵循最佳实践并使用语义版本控制。这在三个层次上定义了API的兼容性:

补丁——你根本不需要修改你的代码。这个库只是修复了一些错误。 次要-你不需要改变你的代码，因为添加的东西(开闭原则是尊重的) 重要—接口(API)已更改，您可能需要更改代码。

为了让你使用同一个库的一个新的主要版本，还有很多其他的约定需要遵守:

库使用的二进制语言(在Java情况下是定义Java字节码的JVM目标版本) 调用约定 JVM规范 链接约定 运行时约定 所有这些都是由我们使用的工具定义和管理的。

例子

Java案例研究

例如，Java标准化了所有这些约定，不是在一个工具中，而是在一个正式的JVM规范中。该规范允许其他供应商提供一组不同的工具来输出兼容的库。

Java为ABI提供了另外两个有趣的案例研究:Scala版本和Dalvik虚拟机。

Dalvik虚拟机破坏了ABI

The Dalvik VM needs a different type of bytecode than the Java bytecode. The Dalvik libraries are obtained by converting the Java bytecode (with same API) for Dalvik. In this way you can get two versions of the same API: defined by the original joda-time-1.7.2.jar. We could call it joda-time-1.7.2.jar and joda-time-1.7.2-dalvik.jar. They use a different ABI one is for the stack-oriented standard Java vms: Oracle's one, IBM's one, open Java or any other; and the second ABI is the one around Dalvik.

Scala后续版本不兼容

Scala在次要的Scala版本之间不具有二进制兼容性:2。X。由于这个原因，相同的API“io。reactivex" %% "rxscala" % "0.26.5"有三个版本(将来会有更多):针对Scala 2.10、2.11和2.12。改变了什么?我现在不知道，但是二进制文件是不兼容的。可能最新的版本增加了一些东西，使得库在旧的虚拟机上无法使用，可能是与链接/命名/参数约定有关的东西。

Java连续版本是不兼容的

Java在JVM的主要版本上也有问题:4,5,6,7,8,9。它们只提供向后兼容性。Jvm9知道如何运行针对所有其他版本的编译/目标代码(javac的-target选项)，而JVM 4不知道如何运行针对JVM 5的代码。而你只有一个joda-library。由于有不同的解决方案，这种不兼容性变得显而易见:

语义版本控制:当库的目标是更高的JVM时，它们通常会改变主版本。 使用JVM 4作为ABI，您就安全了。 Java 9增加了一个关于如何在同一个库中包含特定目标JVM的字节码的规范。

为什么我要从API定义开始呢?

API and ABI are just conventions on how you define compatibility. The lower layers are generic in respect of a plethora of high level semantics. That's why it's easy to make some conventions. The first kind of conventions are about memory alignment, byte encoding, calling conventions, big and little endian encodings, etc. On top of them you get the executable conventions like others described, linking conventions, intermediate byte code like the one used by Java or LLVM IR used by GCC. Third you get conventions on how to find libraries, how to load them (see Java classloaders). As you go higher and higher in concepts you have new conventions that you consider as a given. That's why they didn't made it to the semantic versioning. They are implicit or collapsed in the major version. We could amend semantic versioning with <major>-<minor>-<patch>-<platform/ABI>. This is what is actually happening already: platform is already a rpm, dll, jar (JVM bytecode), war(jvm+web server), apk, 2.11 (specific Scala version) and so on. When you say APK you already talk about a specific ABI part of your API.

API可以移植到不同的ABI

抽象的顶层(针对最高API编写的源代码可以被重新编译/移植到任何其他较低层次的抽象。

假设我有一些rxscala的源代码。如果Scala工具改变了，我可以重新编译它们。如果JVM发生了变化，我就可以从旧机器自动转换到新机器，而不需要考虑高级概念。虽然移植可能很困难，但对任何其他客户端都有帮助。如果使用完全不同的汇编代码创建一个新的操作系统，则可以创建一个转换器。

跨语言移植的api

有些api可以移植到多种语言中，比如反应流。一般来说，它们定义到特定语言/平台的映射。我认为API是用人类语言甚至是特定的编程语言正式定义的主规范。在某种意义上，所有其他的“映射”都是ABI，比通常的ABI更多的API。REST接口也是如此。

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

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

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

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

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

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

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

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

希望这能有所帮助!

术语ABI用于指代两个不同但相关的概念。

当谈到编译器时，它指的是用于从源级结构转换到二进制结构的规则。数据类型有多大?堆栈是如何工作的?如何将参数传递给函数?调用者和被调用者应该保存哪些寄存器?

当谈到库时，它指的是由编译库提供的二进制接口。这个接口是多种因素的结果，包括库的源代码、编译器使用的规则，以及在某些情况下从其他库中获得的定义。

对库的更改可以在不破坏API的情况下破坏ABI。例如，考虑具有如下接口的库。

void initfoo(FOO * foo)
int usefoo(FOO * foo, int bar)
void cleanupfoo(FOO * foo)

应用程序程序员编写的代码是

int dostuffwithfoo(int bar) {
  FOO foo;
  initfoo(&foo);
  int result = usefoo(&foo,bar)
  cleanupfoo(&foo);
  return result;
}

应用程序程序员并不关心FOO的大小或布局，但应用程序二进制文件最终会硬编码FOO的大小。如果标准库程序员在foo中添加了一个额外的字段，并且有人将新的标准库二进制文件与旧的应用程序二进制文件一起使用，那么标准库可能会进行越界内存访问。

OTOH，如果标准库的作者像这样设计他们的API。

FOO * newfoo(void)
int usefoo(FOO * foo, int bar)
void deletefoo((FOO * foo, int bar))

应用程序程序员编写的代码是

int dostuffwithfoo(int bar) {
  FOO * foo;
  foo = newfoo();
  int result = usefoo(foo,bar)
  deletefoo(foo);
  return result;
}

然后，应用程序二进制文件不需要知道任何关于FOO的结构，这些都可以隐藏在库中。你为此付出的代价是涉及到堆操作。

Linux共享库最小可运行ABI示例

在共享库的上下文中，“拥有稳定的ABI”最重要的含义是，在库更改后不需要重新编译程序。

例如:

如果您正在销售一个共享库，您可以为用户省去为每个新版本重新编译依赖于您的库的所有内容的麻烦 如果您正在销售依赖于用户发行版中的共享库的闭源程序，如果您确定ABI在目标操作系统的某些版本上是稳定的，那么您可以发布和测试更少的预构建。 这在C标准库的情况下尤其重要，您的系统中有许多程序都链接到C标准库。

现在我想提供一个最小的具体可运行的示例。

c

#include <assert.h>
#include <stdlib.h>

#include "mylib.h"

int main(void) {
    mylib_mystruct *myobject = mylib_init(1);
    assert(myobject->old_field == 1);
    free(myobject);
    return EXIT_SUCCESS;
}

mylib.c

#include <stdlib.h>

#include "mylib.h"

mylib_mystruct* mylib_init(int old_field) {
    mylib_mystruct *myobject;
    myobject = malloc(sizeof(mylib_mystruct));
    myobject->old_field = old_field;
    return myobject;
}

mylib.h

#ifndef MYLIB_H
#define MYLIB_H

typedef struct {
    int old_field;
} mylib_mystruct;

mylib_mystruct* mylib_init(int old_field);

#endif

编译和运行良好:

cc='gcc -pedantic-errors -std=c89 -Wall -Wextra'
$cc -fPIC -c -o mylib.o mylib.c
$cc -L . -shared -o libmylib.so mylib.o
$cc -L . -o main.out main.c -lmylib
LD_LIBRARY_PATH=. ./main.out

现在，假设对于标准库的v2，我们希望向mylib_mystruct添加一个名为new_field的新字段。

如果我们在old_field之前添加字段，如下所示:

typedef struct {
    int new_field;
    int old_field;
} mylib_mystruct;

重建了图书馆，但不是主要的。Out，则断言失败!

这是因为这一行:

myobject->old_field == 1

已生成程序集，该程序集试图访问结构体的第一个int，该结构体现在是new_field，而不是预期的old_field。

因此，这个更改破坏了ABI。

但是，如果我们在old_field之后添加new_field:

typedef struct {
    int old_field;
    int new_field;
} mylib_mystruct;

那么旧生成的程序集仍然访问结构的第一个int，程序仍然可以工作，因为我们保持了ABI的稳定。

下面是这个例子在GitHub上的一个全自动版本。

保持此ABI稳定的另一种方法是将mylib_mystruct视为不透明结构，仅通过方法帮助程序访问其字段。这样可以更容易地保持ABI的稳定，但是由于我们要进行更多的函数调用，因此会产生性能开销。

API 与 ABI

在前面的例子中，有趣的是，在old_field之前添加new_field只破坏了ABI，而没有破坏API。

这意味着，如果我们根据标准库重新编译main.c程序，无论如何它都会工作。

然而，如果我们改变了例如函数签名，我们也会破坏API:

mylib_mystruct* mylib_init(int old_field, int new_field);

因为在这种情况下，main.c将完全停止编译。

语义API vs编程API

我们还可以将API更改分为第三种类型:语义更改。

语义API通常是API应该做什么的自然语言描述，通常包含在API文档中。

因此，可以在不破坏程序构建本身的情况下破坏语义API。

例如，如果我们修改了

myobject->old_field = old_field;

to:

myobject->old_field = old_field + 1;

那么这既不会破坏编程API，也不会破坏ABI，但是main.c语义API会破坏。

有两种方法可以通过编程方式检查合约API:

测试一些极端情况。这很简单，但你可能总是错过一个。 正式的验证。更难做到，但产生了正确性的数学证明，本质上是将文档和测试统一为“人”/机器可验证的方式!当然，前提是你的正式描述中没有bug;-) 这个概念与数学本身的形式化密切相关:https://math.stackexchange.com/questions/53969/what-does-formal-mean/3297537#3297537

打破C / c++共享库abi的所有东西的列表

待办事项:查找/创建最终列表:

https://github.com/lvc/abi-compliance-checker自动化工具进行检查 https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B KDE c++ ABI指南 https://plan99.net/~mike/writing-shared-libraries.html

Java最小可运行示例

Java中的二进制兼容性是什么?

在Ubuntu 18.10, GCC 8.2.0中测试。

应用二进制接口(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).