ARM ABI和EABI的目的是什么?

Mic*_*cro 33 arm abi eabi

我越看这篇PDF,我就越不明白这意味着什么.另外,我想对其他人12发表一些评论.

Fra*_*kH. 70

ABI(应用程序二进制接口)是一种标准,它定义了高级语言中的低级概念与特定硬件/ OS平台的机器代码的能力之间的映射.这包括以下内容:

  • C/C++/Fortran/... 数据类型如何在内存中布局(数据大小/对齐)
  • 嵌套函数调用是如何工作的(在何处以及如何存储关于如何返回函数调用者的信息,在CPU寄存器和/或内存函数参数中传递的位置)
  • 程序启动/初始化如何工作("可执行文件"具有什么数据格式,如何从那里加载代码/数据,DLL如何工作......)

这些答案是:

  • 语言特定(因此你有一个C ABI,C++ ABI,Fortran ABI,Pascal ABI,......甚至Java字节码规范,虽然针对的是"虚拟"处理器而不是真正的硬件,但是是ABI),
  • 特定于操作系统(MS Windows和Linux在同一硬件上使用不同的ABI),
  • 硬件/ CPU特定(ARM和x86 ABI不同).
  • (长)时间的演变(现有的ABI经常被更新/修改,以便可以使用新的CPU功能,例如,指定如何使用x86 SSE寄存器应用程序当然只能使用一次CPU 这些注册表,因此需要澄清现有的ABI).

如果没有某种标准化,不同编译器创建的(机器)代码就无法使用相同类型的库(您如何知道库代码需要以哪种方式传递函数参数或数据结构?).

每个平台(特定硬件,操作系统软件和用特定编程语言编写的代码/用特定编译器编译的组合)定义了一整套ABI,以使事物可互操作.这个领域的术语不清楚,有时人们只是谈论"ABI",有时候它被称为"平台补充",或者人们提到编程语言并说例如"C++ ABI".请记住,没有一件这样的事情.

您在问题中链接到的文档都是此类的特定示例(语言/操作系统/硬件特定的ABI).

即使在特定平台上,也没有必要只有一个 ABI(集合),因为不同的此类约定可能具有不同的优势(因此提供更好的性能/更小的代码/更好的内存使用/ ...... - 取决于程序)系统设计师通常会尝试灵活/允许.
例如,在32位Microsoft Windows上,有许多用于函数调用约定部分的ABI(fastcall,stdcall,pascal,...).

无论如何,一个通用的stackoverflow搜索"ABI"(包括"相关"侧栏下的链接)给了很多线索来研究这个问题,我现在关闭了我的答案.


Cha*_*pul 21

当使用ARM上的OS内核端口时,应该引用ARM ABI.

EABI是处理器启动以加载没有中间内核的应用程序.(当DOS出现时,曾经有类似于ROM-BASIC的东西),即固件本身是独立的应用程序,没有特定于板的显示器或任何东西.

第一个链接是与ARM ABI的过程调用相关的详细子部分.随着程序员的模型随着每个版本的ARM CPU而发展,这些主题很重要并且由ABI涵盖.

第二个链接是关于由OS供应商品牌SCO指定的编译器ELF生成的目标文件的二进制格式规范.也许SCO是Santa Cruz组织,它自己也有Unix和Linux的风格,但是这个故事偏离了这个问题.如果您打算实现支持ELF定位ARM的链接器,您应该对此感兴趣.

除非您直接关注ARM构建工具链的实现细节,否则EABI应该没什么问题,除非您考虑到此类工具链的操作系统特定方面,因此ARM ABI也应该没什么问题.

  • 这是不正确的.简单地说,ABI描述了数据在函数之间传递的方式 - 无论是否涉及操作系统.EABI是ARM上可用的ABI之一,在操作系统的上下文中非常相关(参见[here](https://wiki.debian.org/ArmEabiPort)) (6认同)