什么是应用程序二进制接口（ABI）？ [英] What is Application Binary Interface (ABI)?

问题描述

我从来没有明白什么是ABI。对于这么长的问题，我很抱歉。我只是想清楚地了解事情。请不要指向我的wiki文章，如果可以理解它，我不会在这里发布这么长的帖子。

这是我的心态关于不同的接口：

电视遥控器是用户和电视之间的接口。它是一个现有的实体，但是没有用（自身不提供任何功能）。

接口：它可以在电视机上实现。是该
功能的
功能和消费者之间的现有实体一个，接口本身
是不做任何事情。它只是
调用位于
后面的功能。

现在取决于用户是谁
是不同类型的接口。 / p>

命令行界面（CLI）命令是现有实体，
consumer是用户和功能
。

功能：我的软件
功能解决了我们要描述的某些
目的
此界面。

现有实体：命令

consumer：用户

图形用户界面按钮等是现有的
实体，消费者是用户
并且功能在后面。

功能： 我的软件
功能解决了一些
的目的，我们正在描述
这个接口。

code>现有实体：窗口，按钮
等。

code> user

应用程序接口（API）函数或
更正确，接口$ b接口的编程）是
现有实体，消费者这里是
另一个程序不是用户。并再次
功能位于这一层之后。

功能：我的软件
功能解决了我们要描述的某些
目的
此接口。

现有实体：函数，
接口。

consumer：另一个
程序/应用程序。

应用程序二进制接口（ABI）这是我的问题开始。

功能：

现有实体：

consumer：？





• 我已经用不同的语言写了几个软件，并提供了不同种类的接口API），但我不确定，如果我曾经提供任何ABI。

维基百科说：

ABIs涵盖

• 数据类型，大小和对齐方式;


• 调用约定，它控制函数的参数是如何
  传递和返回值检索;


• 系统调用号码以及应用程序如何向操作系统发出系统调用
  ;

其他ABI可标准化诸如

的详细信息

• 在同一个平台上的编译器之间调用约定，



<
不需要跨平台
兼容性。

• 谁需要这些详细资料？请不要说，操作系统。我知道汇编程序。我知道如何连接&装载工程。我知道里面究竟发生了什么。




• C ++名称漫游在哪里？我想我们在二进制级别上说话。

无论如何，我已下载了 [PDF]系统V应用程序二进制界面版本4.1（1997-03-18） 看看它包含什么。

• 为什么它包含2个章节（第4和第5）描述 ELF 文件格式。实际上，这些是规范中唯一的2个重要章节。其余章节特定于处理器。无论如何，我认为这是完全不同的主题。请不要说ELF文件格式规范是 ABI。根据定义，它不符合接口。




• 我知道，由于我们在这么低的层次上说话，必须非常具体。




• 我在哪里可以找到MS Window的ABI？

所以，这些都是主要的查询。

解决方案

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

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

ABI非常相似。将其视为API的编译版本（或机器语言级别的API）。当您编写源代码时，您通过API访问库。一旦编译代码，您的应用程序通过ABI访问库中的二进制数据。 ABI定义了编译应用程序用于访问外部库（就像API一样）的结构和方法，只有较低的级别。

ABI很重要当涉及到使用外部库的应用程序。如果一个程序被构建为使用一个特定的库并且该库以后被更新，你不想重新编译该应用程序（从最终用户的角度来看，你可能没有源代码）。如果更新的库使用相同的ABI，则您的程序不需要更改。到库的接口（这是所有你的程序真正关心的）是相同的，即使内部工作可能已经改变。具有相同ABI的库的两个版本有时称为二进制兼容，因为它们具有相同的低级接口（您应该能够用新版本替换旧版本，没有任何主要问题）。

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

理由，图书馆作家倾向于保持他们的ABI稳定（以最小化中断）。保持ABI稳定意味着不改变函数接口（返回类型和数量，类型和参数顺序），数据类型或数据结构的定义，定义的常量等。可以添加新的函数和数据类型，但是现有的必须保留一样。如果将一个16位数据结构字段扩展为32位字段，则使用该数据结构的已编译代码将不会正确访问该字段（或其后的任何字段）。访问数据结构成员在编译期间会转换为内存地址和偏移量，如果数据结构发生变化，那么这些偏移量不会指向代码预期指向的值，并且结果最多不可预测。

ABI不一定是你明确提供的东西，除非你希望人们使用汇编接口你的代码。它不是语言特定的，因为（例如）C应用程序和Pascal应用程序将在编译后使用相同的ABI。

编辑：关于您对有关SysV ABI文档中ELF文件格式的章节的问题：包含此信息的原因是因为ELF格式定义操作系统和应用程序之间的接口。当你告诉操作系统运行程序时，它期望程序以某种方式格式化，并且（例如）期望二进制的第一部分是包含特定存储器偏移量的某些信息的ELF头部。这是应用程序如何将关于自身的重要信息传送到操作系统。如果以非ELF二进制格式（例如a.out或PE）构建程序，那么期望ELF格式化应用程序的操作系统将无法解释二进制文件或运行应用程序。这是为什么Windows应用程序不能直接在Linux机器上运行（反之亦然），而不是重新编译或在可以从一种二进制格式转换到另一种二进制格式的某种类型的仿真层内运行的一个重要原因。

IIRC，Windows目前使用便携式可执行文件（或，PE）格式。在维基百科页面的外部链接部分中有链接，其中包含有关PE格式的更多信息。

此外，关于您关于C ++名称调整的注意事项：ABI可以定义一个标准化的方式为C ++编译器做名称调整为兼容性的目的。也就是说，如果我创建一个库并且开发一个使用该库的程序，你应该能够使用一个不同于我所使用的编译器，而不必担心由于不同的名称压缩方案导致的二进制文件不兼容。这真的只有在你定义一个新的二进制文件格式或编写一个编译器或链接器时才有用。

I never clearly understood what is an ABI. I'm sorry for such a lengthy question. I just want to clearly understand things. Please don't point me to wiki article, If could understand it, I wouldn't be here posting such a lengthy post.

This is my mindset about different interfaces:

TV remote is an interface between user and TV. It is an existing entity but useless (doesn't provide any functionality) by itself. All the functionality for each of those buttons on the remote is implemented in the Television set.

Interface: It is a "existing entity" layer between the functionality and consumer of that functionality. An, interface by itself is doesn't do anything. It just invokes the functionality lying behind.

Now depending on who the user is there are different type of interfaces.

Command Line Interface(CLI) commands are the existing entities, consumer is the user and functionality lies behind.

functionality: my software functionality which solves some purpose to which we are describing this interface.

existing entities: commands

consumer: user

Graphical User Interface(GUI) window,buttons etc.. are the existing entities, again consumer is the user and functionality lies behind.

functionality: my software functionality which solves some purpose to which we are describing this interface.

existing entities: window,buttons etc..

consumer: user

Application Programming Interface(API) functions or to be more correct, interfaces (in interfaced based programming) are the existing entities, consumer here is another program not a user. and again functionality lies behind this layer.

functionality: my software functionality which solves some purpose to which we are describing this interface.

existing entities: functions, Interfaces(array of functions).

consumer: another program/application.

Application Binary Interface (ABI) Here is my problem starts.

functionality: ???

existing entities: ???

consumer: ???

• I've wrote few softwares in different languages and provided different kind of interfaces (CLI, GUI, API) but I'm not sure, if I ever, provided any ABI.

Wikipedia says:

ABIs cover details such as

• data type, size, and alignment;
• the calling convention, which controls how functions' arguments are passed and return values retrieved;
• the system call numbers and how an application should make system calls to the operating system;

Other ABIs standardize details such as

• the C++ name mangling,[2] .
• exception propagation,[3] and
• calling convention between compilers on the same platform, but do not require cross-platform compatibility.

• Who needs these details? Please don't say, OS. I know assembly programming. I know how linking & loading works. I know what exactly happens inside.

• Where did C++ name mangling come in between? I thought we are talking at the binary level. Where did languages come in between?

anyway, I've downloaded the [PDF] System V Application Binary Interface Edition 4.1 (1997-03-18) to see what exactly it contains. Well, most of it didn't make any sense.

• Why does it contain 2 chapters (4th & 5th) which describe the ELF file format.Infact, these are the only 2 significant chapters that specification. Rest of all the chapters "Processor Specific". Anyway, I thought that it is completely different topic. Please don't say that ELF file format specs are the ABI. It doesn't qualify to be Interface according to the definition.

• I know, since we are talking at such low level it must be very specific. But I'm not sure how is it "Instruction Set Architecture(ISA)" specific?

• Where can I find MS Window's ABI?

So, these are the major queries that are bugging me.

解决方案

One easy way to understand "ABI" is to compare it to "API".

You are already familiar with the concept of an API. If you want to use the features of, say, some library or your OS, you will use an API. The API consists of data types/structures, constants, functions, etc that you can use in your code to access the functionality of that external component.

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 though 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.

ABIs are important when it comes to applications that use external libraries. If a program is built to use a particular library and that library is later updated, you don't want to have to re-compile that application (and from the end-user's standpoint, you may not have the source). If the updated library uses the same ABI, then your program will not need to change. The interface to the library (which is all your program really cares about) is the same even though the internal workings may have changed. Two versions of a library that have the same ABI are sometimes called "binary-compatible" since they have the same low-level interface (you should be able to replace the old version with the new one and not have any major problems).

Sometimes, ABI changes are unavoidable. When this happens, any programs that use that library will not work unless they are re-compiled to use the new version of the library. If the ABI changes but the API does not, then the old and new library versions are sometimes called "source compatible". This implies that while a program compiled for one library version will not work with the other, source code written for one will work for the other if re-compiled.

For this reason, library writers 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 you expand, say, a 16-bit data structure field into a 32-bit field, then already-compiled code that uses that data structure 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.

An ABI isn't necessarily something you will explicitly provide unless you are expecting people to interface with your code using assembly. It isn't language-specific either, since (for example) a C application and a Pascal application will use the same ABI after they are compiled.

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 currently uses the Portable Executable (or, PE) format. There are links in the "external links" section of that Wikipedia page with more information about the PE format.

Also, regarding your note about C++ name mangling: The ABI can define a "standardized" way for a C++ compiler to do name mangling for the purpose of compatibility. That is, if I create a library and you develop a program that uses the library, you should be able to use a different compiler than I did and not have to worry about the resulting binaries being incompatible due to different name mangling schemes. This is really only of use if you are defining a new binary file format or writing a compiler or linker.

这篇关于什么是应用程序二进制接口（ABI）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！