我一直不清楚ABI是什么。别给我指维基百科上的文章。如果我能理解,我就不会在这里发这么长的帖子了。

这是我对不同界面的看法:

电视遥控器是用户和电视之间的接口。它是一个现有的实体,但本身无用(不提供任何功能)。遥控器上每个按钮的所有功能都在电视机中实现。

Interface: It is an "existing entity" layer between the functionality and consumer of that functionality. An interface by itself 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, the 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, and again the consumer is the user and functionality lies behind. functionality: my software functionality which solves some problem 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 problem to which we are describing this interface. existing entities: functions, Interfaces (array of functions). consumer: another program/application. Application Binary Interface (ABI) Here is where my problem starts. functionality: ??? existing entities: ??? consumer: ???

我用不同的语言编写过软件,并提供过不同类型的接口(CLI、GUI和API),但我不确定是否曾经提供过ABI。

维基百科说:

abi涵盖了诸如 数据类型、大小和对齐方式; 调用约定,它控制函数的实参 传递和返回检索到的值; 系统调用编号以及应用程序应该如何进行系统调用 到操作系统; 其他abi标准化细节,如 c++名字mangling, 异常传播,以及 调用约定的编译器之间在同一平台,但做 不需要跨平台兼容性。

谁需要这些细节?请不要说操作系统。我懂汇编编程。我知道如何链接和加载工作。我知道里面发生了什么。 为什么c++会出现名字混淆?我以为我们是在谈论二元的层面。为什么会出现语言?

无论如何,我已经下载了[PDF] System V应用程序二进制接口版4.1(1997-03-18)来看看它到底包含了什么。大部分都说不通啊。

Why does it contain two chapters (4th & 5th) to describe the ELF file format? In fact, these are the only two significant chapters of that specification. The rest of the chapters are "processor specific". Anyway, I though that it is a completely different topic. Please don't say that ELF file format specifications are the ABI. It doesn't qualify to be an interface according to the definition. I know, since we are talking at such a low level it must be very specific. But I'm not sure how is it "instruction set architecture (ISA)" specific? Where can I find Microsoft Windows' ABI?

这些是困扰我的主要问题。


当前回答

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

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

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

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

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

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

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

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的目的是在二进制/汇编级别定义软件的精确集成。

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

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

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

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

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

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

当然,还有许多其他细节,但这主要是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又不同了。

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

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

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

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

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