总结

对于定义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可以被看作是一种软件东西一起工作的东西。

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

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

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

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

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

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

理解“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)

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模块稳定性和库稳定性]