oabi/eabi

ABI(Application Binary Interface)或EABI(Extend ABI)通常是处理器体系结构的一部分,它与平台是紧密相连的。
我们可以把ABI理解为一套规则,这套规则一般包括定义了以下内容:

1。应用程序如何发出系统调用来trap到内核态。
2。如何使用机器的寄存器。比如,RISC处理器的ABI就要规定用那个通用寄存器来作stack pointer和frame pointer。
3。规定如何进行procedure call。


那么eabi和oabi的差别, The ARM EABI improves the floating point performance

a) 无论是否有FPU,浮点执行非常迅速。软件浮点和硬件浮点代码可以混合。
b)Structure packing is not as painful as it used to be
c) More compatibility with various tools (in future - currently linux-elf is well supported)
d)更有效的 syscall 调用(这个影响很大)

 

在前面的文章中,系统调用有一定的差别。

那么我们 如何确认这个toolchain支持或不支吃eabi呢?

如下,我编译一个文件

[root@cybertan test]# gcc -mabi=eabi liyi.c -o liyi
cc1: error: unrecognized command line option "-mabi=eabi"

 

[root@cybertan test]# mipsel-linux-gcc -mabi=eabi liyi.c -o liyi
liyi.c: In function `main':
liyi.c:12: warning: return type of `main' is not `int'
/tmp/ccKPGIoX.s: Assembler messages:
/tmp/ccKPGIoX.s:24: Error: illegal operands `lui'
/tmp/ccKPGIoX.s:25: Error: illegal operands `addiu'
/tmp/ccKPGIoX.s:26: Error: opcode not supported on this processor: R3000 (MIPS1) `daddu $gp,$1,$25'
/tmp/ccKPGIoX.s:34: Warning: No .cprestore pseudo-op used in PIC code


一般来说,应用程序,以及库以及kernel,如果有一方使用eabi来编译,那么另外一方也需要采用eabi的方式,不然可能出现crash的情况。


[root@cybertan sbin]# mipsel-linux-readelf -h rc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x406530
  Start of program headers:          52 (bytes into file)
  Start of section headers:          532868 (bytes into file)
  Flags:                             0x5, noreorder, cpic, mips1
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         24
  Section header string table index: 23

 

上面有关于abi的信息。


网络上有关于abi以及eabi的说法,只针对arm体系


首先,我们先看一下ARM处理器是如何处理浮点运算的。
交叉编译器在编译的时候,对于浮点运行会预设硬浮点运算FPA(Float Point Architecture),而没有FPA的CPU,比如SAMSUNG S3C2410/S3C2440,会使用FPE(Float Point Emulation 即软浮点),这样在速度上就会遇到极大的限制。也就是说如果有浮点协处理器则交给它去做,如果没有则会产生一个陷阱(trap,处理器响应异常的机制), 而我们事先准备好针对浮点指令的陷阱处理程序就可以通过软件来模拟浮点运算指令。


以下部分转载至http://linux.chinaunix.net/bbs/thread-1143604-1-1.html。
1。什么是ABI
ABI,application binary interface (ABI),应用程序二进制接口。
既然是 接口,那就是某两种东西之间的沟通桥梁,此处有这些种情况:
A。应用程序 <-> 操作系统;
B。应用程序 <-> (应用程序所用到的)库
C 。应用程序各个组件之间

类似于API的作用是使得程序的代码间的兼容,ABI目的是使得程序的二进制(级别)的兼容。

2。什么是OABI 和 EABI
OABI中的O,表示“Old”,“Lagacy”,旧的,过时的,OABI就是旧的/老的ABI。
EABI中的E,表示“Embedded”,是一种新的ABI。
EABI有时候也叫做GNU EABI。
OABI和EABI都是专门针对ARM的CPU来说的。

3。EABI的好处 / 为何要用EABI
A。支持软件浮点和硬件实现浮点功能混用
B。系统调用的效率更高
C。后今后的工具更兼容
D。软件浮点的情况下,EABI的软件浮点的效率要比OABI高很多。

4。OABI和EABI的区别
两种ABI在如下方面有区别:
A。调用规则(包括参数如何传递及如何获得返回值)
B。系统调用的数目以及应用程序应该如何去做系统调用
C。目标文件的二进制格式,程序库等
D。结构体中的 填充(padding/packing)和对齐

 

 

在使用的时候:(主要在编译crosstool的时候设置)

传统的ABI和EABI 区别


    Legacy ABI                                                                 
1)ABI flags passed to binutils: - mabi =apcs-gnu -mfpu=fpa     
2)gcc -dumpmachine: arm-unknown-linux

    EABI
1)ABI flags passed by gcc to binutils: -mabi =aapcs-linux -mfloat-abi=soft -meabi=4
2)gcc -dumpmachine: arm-unknown-linux-gnueabi

从ELF文件中查询:
执行“readelf -h | grep Flags”
Lagacy ABI:                               EABI :
Flags:0x0                                 Flags: 0x4000002, has entry point, Version4 EABI


你可能感兴趣的:(header,gcc,File,application,interface,structure)