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

现有实体:参数布局、函数语义、寄存器分配。例如，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又不同了。

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

现有实体:参数布局、函数语义、寄存器分配。例如，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又不同了。

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中最重要的部分。

为了调用共享库中的代码，或者在编译单元之间调用代码，object文件需要包含调用的标签。c++修改了方法标签的名称，以加强数据隐藏并允许重载方法。这就是为什么您不能混合来自不同c++编译器的文件，除非它们显式地支持相同的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的目的是在二进制/汇编级别定义软件的精确集成。