我一直不清楚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用于指代两个不同但相关的概念。
当谈到编译器时,它指的是用于从源级结构转换到二进制结构的规则。数据类型有多大?堆栈是如何工作的?如何将参数传递给函数?调用者和被调用者应该保存哪些寄存器?
当谈到库时,它指的是由编译库提供的二进制接口。这个接口是多种因素的结果,包括库的源代码、编译器使用的规则,以及在某些情况下从其他库中获得的定义。
对库的更改可以在不破坏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的结构,这些都可以隐藏在库中。你为此付出的代价是涉及到堆操作。
我也试图理解ABI, JesperE的回答很有帮助。
从一个非常简单的角度来看,我们可以尝试通过考虑二进制兼容性来理解ABI。
KDE wiki将库定义为二进制兼容的,“如果动态链接到库的前版本的程序继续与库的新版本一起运行,而不需要重新编译”。有关动态链接的更多信息,请参阅静态链接与动态链接
现在,让我们试着看看一个库需要二进制兼容性的最基本方面(假设库没有源代码更改):
相同/向后兼容的指令集架构(处理器指令、寄存器文件结构、堆栈组织、内存访问类型,以及处理器可以直接访问的基本数据类型的大小、布局和对齐)
相同调用约定
同名混淆约定(如果Fortran程序需要调用一些c++库函数,这可能是需要的)。
当然,还有许多其他细节,但这主要是ABI所涵盖的内容。
更具体地回答你的问题,由以上,我们可以推断:
ABI功能:二进制兼容性
现有实体:现有程序/库/操作系统
消费者:库,操作系统
希望这能有所帮助!
实际上你根本不需要ABI如果
你的程序没有函数,而且——
你的程序是一个单独运行的可执行文件(即一个嵌入式系统),它实际上是唯一在运行的东西,它不需要与其他任何东西对话。
过度简化的总结:
API:“这里是你可以调用的所有函数。”
ABI:“这是调用函数的方法。”
ABI是编译器和链接器遵守的一组规则,以便编译您的程序,使其正常工作。ABIs涵盖多个主题:
Arguably the biggest and most important part of an ABI is the procedure call standard sometimes known as the "calling convention". Calling conventions standardize how "functions" are translated to assembly code.
ABIs also dictate the how the names of exposed functions in libraries should be represented so that other code can call those libraries and know what arguments should be passed. This is called "name mangling".
ABIs also dictate what type of data types can be used, how they must be aligned, and other low-level details.
更深入地了解调用约定,我认为它是ABI的核心:
机器本身没有“功能”的概念。当你用高级语言(如c)编写函数时,编译器会生成一行汇编代码,如_MyFunction1:。这是一个标签,它最终将被汇编程序解析为一个地址。这个标签标记了程序集代码中“函数”的“开始”。在高级代码中,当你“调用”这个函数时,你真正做的是导致CPU跳转到那个标签的地址并继续在那里执行。
在为跳转做准备时,编译器必须做一些重要的事情。调用约定就像一个清单,编译器遵循它来完成所有这些事情:
First, the compiler inserts a little bit of assembly code to save the current address, so that when your "function" is done, the CPU can jump back to the right place and continue executing.
Next, the compiler generates assembly code to pass the arguments.
Some calling conventions dictate that arguments should be put on the stack (in a particular order of course).
Other conventions dictate that the arguments should be put in particular registers (depending on their data types of course).
Still other conventions dictate that a specific combination of stack and registers should be used.
Of course, if there was anything important in those registers before, those values are now overwritten and lost forever, so some calling conventions may dictate that the compiler should save some of those registers prior to putting the arguments in them.
Now the compiler inserts a jump instruction telling the CPU to go to that label it made previously (_MyFunction1:). At this point, you can consider the CPU to be "in" your "function".
At the end of the function, the compiler puts some assembly code that will make the CPU write the return value in the correct place. The calling convention will dictate whether the return value should be put into a particular register (depending on its type), or on the stack.
Now it's time for clean-up. The calling convention will dictate where the compiler places the cleanup assembly code.
Some conventions say that the caller must clean up the stack. This means that after the "function" is done and the CPU jumps back to where it was before, the very next code to be executed should be some very specific cleanup code.
Other conventions say that the some particular parts of the cleanup code should be at the end of the "function" before the jump back.
有许多不同的abi /调用约定。主要有:
x86或x86-64 CPU(32位环境):
CDECL
STDCALL
FASTCALL
VECTORCALL
THISCALL
x86-64(64位环境):
SYSTEMV
MSNATIVE
VECTORCALL
ARM CPU(32位)
AAPCS
ARM处理器(64位)
AAPCS64
这里有一个很棒的页面,它实际显示了为不同的abi编译时生成的程序集的差异。
另一件需要提及的事情是,ABI不仅仅与程序的可执行模块内部相关。链接器还使用它来确保程序正确调用库函数。您的计算机上运行着多个共享库,只要编译器知道它们各自使用的ABI,它就可以正确地从它们调用函数,而不会破坏堆栈。
编译器理解如何调用库函数是非常重要的。在一个托管平台上(也就是说,一个OS加载程序的平台),如果不调用内核,您的程序甚至不能闪烁。