总结

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

在我看来，ABI是特定API的给定/平台的主观约定。ABI是特定API“不会改变”或将由运行时环境处理的“其余”约定：执行器、工具、链接器、编译器、jvm和操作系统。

定义接口：ABI、API

如果您想使用像joda-time这样的库，您必须声明对joda-time-<major>.<minor>.<patch>.jar的依赖。该库遵循最佳实践并使用语义版本控制。这在三个级别定义了API兼容性：

1. 补丁-您根本不需要更改代码。该库只是修复了一些错误。
2. 未成年人-你不需要改变你的代码，因为添加的东西（开放封闭原则得到尊重）
3. 主要-接口（API）已更改，您可能需要更改代码。

为了让您使用同一个库的新主要版本，仍然需要尊重许多其他约定：

• 用于库的二进制语言（在Java情况下是定义Java字节码的JVM目标版本）
• 召集公约
• JVM约定
• 链接约定
• 运行时约定 所有这些都由我们使用的工具定义和管理。

示例

Java案例研究

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

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

Dalvik虚拟机打破了ABI

Dalvik虚拟机需要与Java字节码不同类型的字节码。Dalvik库是通过为Dalvik转换Java字节码（具有相同API）获得的。通过这种方式，你可以获得相同API的两个版本：由原始joda-time-1.7.2.jar定义。我们可以称之为joda-time-1.7.2.jar和joda-time-1.7.2-dalvik.jar。它们使用不同的ABI用于面向堆栈的标准Java虚拟机：Oracle的一个、IBM的一个、开放Java或任何其他；第二个ABI是Dalvik周围的ABI。

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库的情况下发生的。由于不同的解决方案，这种不兼容性在雷达下飞翔：

1. 语义版本控制：当库面向更高的JVM时，它们通常会更改主要版本。
2. 使用JVM 4作为ABI，您是安全的。
3. Java9添加了关于如何在同一个库中包含特定目标JVM的字节码的规范。

为什么我从API定义开始？

API和ABI只是关于如何定义兼容性的约定。较低层在大量高级语义学方面是通用的。这就是为什么制定一些约定很容易。第一种约定是关于内存对齐、字节编码、调用约定、大端和小端编码等。在它们之上，你会得到像其他描述的可执行约定，链接约定，中间字节码，就像Java使用的那样，或者GCC使用的LLVM IR。第三，你会得到关于如何查找库、如何加载它们的约定（参见Java类加载器）。随着概念越来越高，你会有新的约定，你认为这些约定是给定的。这就是为什么他们没有进入语义版本控制。它们在主要版本中是隐式的或折叠的。我们可以用<major>-<minor>-<patch>-<platform/ABI>修改语义版本控制。这实际上已经发生了：平台已经是rpm、dll、jar（JVM字节码）、war（jvm+Web服务器）、apk、2.11（特定的Scala版本）等。当你说APK时，你已经谈论了API的特定ABI部分。

API可以移植到不同的ABI

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

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

跨语言移植的API

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

我也试图理解ABI，JesperE的回答非常有帮助。

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

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

现在，让我们尝试看看库二进制兼容性所需的最基本方面（假设库没有源代码更改）：

1. 相同/向下兼容的指令集架构（处理器指令、寄存器文件结构、堆栈组织、内存访问类型，以及处理器可以直接访问的基本数据类型的大小、布局和对齐）
2. 相同的呼叫惯例
3. 同名修饰约定（如果一个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标准库的情况下特别重要，您系统中的许多程序都链接到它。

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

main. 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;

并重建了库，但不是main.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 vs 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;

到：

myobject->old_field = old_field + 1;

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

有两种方法可以以编程方式检查合约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 KDEC++ABI指南
• https://plan99.net/~mike/writing-shared-libraries.html

Java最小可运行示例

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

在Ubuntu 18.10、GCC 8.2.0中测试。

应用程序二进制接口（ABI）

ABI-Application Binary Interface是关于运行时中两个二进制零件之间的机器代码通信-应用程序，库，操作系统…ABI描述了对象如何保存在内存中，函数如何调用（calling convention），修饰…

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

• Application layer-当您使用不同的语言创建应用程序时。例如，您可以使用Swift和Objective-C^{[混合Swift和Objective-C]}创建应用程序

• Application - OS layer-runtime-Swift Standard Library和Swift Run Time Library^关于我们是操作系统的一部分，它们不应该包含在每个包（例如应用程序、框架）中。它与Objective-C的使用相同。可从iOSv12.2获得

• Library layer-Module Stability case-编译时间-您将能够导入使用另一个版本的Swift编译器构建的框架。这意味着创建闭源（预构建）二进制文件是安全的，该二进制文件将被不同版本的编译器使用（.swiftinterface与.swiftmodule^关于我们一起使用），并且您将不会得到

  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

  1. 编译时-如果依赖项已更改，则客户端不得更改 重新编译。
  2. 运行时-系统库或动态框架可以 被一个新的热交换。

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

答：简单地说，ABI与API的一个共同点是它是一个接口。可重用的程序公开了一个稳定的接口（API），可用于在另一个程序中重用该程序。

然而，ABI是为某种特定语言的特定处理器平台发布的接口。所有希望以该语言为目标的编译器供应商都必须确保不仅可重定位目标代码形式的编译代码符合该接口，以便能够相互链接和交叉链接，而且可执行文件也符合该接口，以便能够在该平台上运行。因此，ABI比典型的函数API更广泛的规范/标准集。它可能包括编译器强制执行给语言用户的一些API对象。编译器供应商必须在他们的发行版中包含对相同API的支持。不用说，平台供应商是为其平台发布ABI的合法权威。编译器供应商和ABI都需要遵守相应的语言标准（例如C++的ISO标准）。

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

"1.为了在特定的执行环境中执行，可执行文件必须符合的规范。例如，Arm架构的LinuxABI。

2. 独立生成的可重定位文件必须符合的规范的一个特定方面，才能静态链接和执行。例如，Arm架构的C++ABI、Arm架构的运行时ABI、Arm架构的C库ABI。”

例如，基于安腾架构的C++通用ABI也由一个联盟提出发布。平台供应商自己的C++ABI在多大程度上遵守它完全取决于平台供应商。

再举一个例子，Arm架构的C++ABI是这里。

F.话虽如此，在幕后，处理器架构的ABI将确保一个可重用程序和另一个重用它的程序之间的API适用于该处理器架构。

这就把我们带到了面向服务的组件（例如基于SOAP的Web服务）。它们也需要一个API存在于基于SOAP的Web服务和客户端程序（可以是应用程序、前端或其他Web服务）之间，以便客户端程序重用Web服务。它不针对任何特定的处理器平台，因此它不是像ABI那样的“二进制”。任何一种平台类型并用任何语言编写的客户端程序都可以远程重用用任何其他语言编写并托管在完全不同的处理器平台上的Web服务。这是由于WSDL和SOAP都是基于文本的（XML）协议。对于RESTful Web服务，传输协议超文本传输协议-也是一个基于文本的协议-本身充当API（CRUD方法）。