,初识ELF格式 ABI,EABI,OABI（由gnueabihf想到gnu,eabi,hf ）

最新推荐文章于 2024-07-08 22:09:55 发布

qq_25814297-npl

最新推荐文章于 2024-07-08 22:09:55 发布

阅读量550

点赞数

分类专栏：编程文章标签： linux 运维服务器

原文链接：https://blog.csdn.net/Golden_Chen/article/details/124935880

版权

编程专栏收录该内容

753 篇文章 73 订阅

订阅专栏

hf表示Hard Float 当您使用此标志时，在编译期间，编译器将编译您的程序，以便在启动后使用Floating Point Unit。您的程序运行得更快，但前提是您使用浮点数！如果您的CPU不支持它，或者无法启动它，请不要使用此标志。

编辑：
此外，如果您使用Soft Float，它将计算每个花车＆＃34;软件＆＃34;。

arm - eabihf hf代表什么？ - Thinbug

尽管每天都在调用linux的elf文件做各种事,但却很少去了解他,最近尝试在orangepi上编译个elf到android手机上运行,因为两个CPU都是ARMv8的.结果运行失败了.遂查找原因.结果挖出这玩意...
以下内容大部分为摘抄整理:
关于ABI,EABI,OABI:
ABI(application binary interface)
应用程序二进制接口
一般应用程序是要分各种CPU架构的,ABI用于对接.
而ABI的不同则是linux内核和glibc的升级导致的规范变化导致的。不同的ABI程序和库在不同的环境下很高概率是不能运行的，除非是低版本最原始的ABI在现代系统上跑一般都可以向下兼容。而这种不兼容主要发生在C++身上，因为C++近几年的特性改变速度相对较快，管理困难。X86上常见的elf ABI有：
OS/ABI: UNIX - Linux
OS/ABI: UNIX - System V
OS/ABI: UNIX - GNU
其中GNU和Linux两种是相同的，只是使用不同版本的readelf会现实不同的结果。而system v则是最古老的，也是兼容性最好的。有的老一些的系统上只识别system v的ABI。但是system v ABI for x86_64却是比linux还要先进的ABI。因为这个ABI把大部分的参数转由寄存器传递，而不是由栈传递，对栈的使用减少就增加了以往的缓存溢出的难度。还有x32上的return to libc等攻击的手法也得变通，难度提高。
OABI 的O表示Old,旧的ABI
EABI的E表示Embedded 嵌入式,是描述可连接目标代码，库目标代码，可执行文件映像，如何连接，执行和调试，以及目标代码生成过程，和c, c++语言接口的规范，是编译连接工具的基础规范，也是研究它们工作原理的基础，可惜arm的EABI迄今为止没有完全订好。

EABI的好处／为何要用EABI

支持软件浮点和硬件实现浮点功能混用
系统调用的效率更高
后今后的工具更兼容
软件浮点的情况下，EABI的软件浮点的效率要比OABI高很多。

OABI和EABI的区别

两种ABI在如下方面有区别：

调用规则（包括参数如何传递及如何获得返回值）
系统调用的数目以及应用程序应该如何去做系统调用
目标文件的二进制格式，程序库等
结构体中的填充（padding/packing）和对齐。

以及：

OABI：
* ABI flags passed to binutils: -mabi=apcs-gnu -mfpu=fpa
* gcc -dumpmachine: arm-unknown-linux
* objdump -x for compiled binary:
private flags = 2: [APCS-32] [FPA float format] [has entry point]
* "file" on compiled Debian binary:
ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped
* "readelf -h | grep Flags""
Flags: 0x0
EABI：
* ABI flags passed by gcc to binutils: -mabi=aapcs-linux -mfloat-abi=soft -meabi=4
* gcc -dumpmachine: arm-unknown-linux-gnueabi
* objdump -x for compiled binary:
private flags = 4000002: [Version4 EABI] [has entry point]
* "file" on compiled binary (under Debian):
ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), for GNU/Linux 2.4.17, stripped
* "readelf -h | grep Flags""
Flags: 0x4000002, has entry point, Version4 EABI

关于编译器:

Gcc在编译的时候可以使用--enable-kernel指定最低支持的内核版本，这个选项会在elf头部添加.note.ABI-tag，如果编译的时候加入了-g参数，然后用gdb调试就可以显示。最大程度上查看一个elf文件信息。
Gcc的5.1版本的编译器会在编译时做大量激进的优化，但是有的优化是只对于最新的CPU特性有效，老一些的CPU在硬件层面就不支持这些优化，所以如此编译的程序就有兼容性问题。方法是用更老的编译器或者是用5.2之后解决了这个问题的更新的编译器。
附上elf格式解析: http://i.woblog.cn/2016/08/14/elf-format/

关于调试与分析的一些指令: 19. crontab 定时任务 — Linux Tools Quick Tutorial

file elf文件 #可查看一些elf的架构信息
readelf -a elf文件 #信息更全面
ldd elf文件 #查看一个程序依赖的库
objdump 二进制文件 #objdump工具用来显示二进制文件的信息
nm 目标文件 #nm 命令显示关于指定 File 中符号的信息
size #查看文件映射到内存大小
lsof -c 进程名 #查看一个进程打开的文件
pstack命令可显示每个进程的栈跟踪。pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。此命令允许使用的唯一选项是要检查的进程的 PID。请参见 proc(1) 手册页。这个命令在排查进程问题时非常有用，比如我们发现一个服务一直处于work状态（如假死状态，好似死循环），使用这个命令就能轻松定位问题所在；可以在一段时间内，多执行几次pstack，若发现代码栈总是停在同一个位置，那个位置就需要重点关注，很可能就是出问题的地方；
strace常用来跟踪进程执行时的系统调用和所接收的信号。在Linux世界，进程不能直接访问硬件设备，当进程需要访问硬件设备(比如读取磁盘文件，接收网络数据等等)时，必须由用户态模式切换至内核态模式，通过系统调用访问硬件设备。strace可以跟踪到一个进程产生的系统调用,包括参数，返回值，执行消耗的时间。
ipcs是Linux下显示进程间通信设施状态的工具,可以显示消息队列、共享内存和信号量的信息。对于程序员非常有用，普通的系统管理员一般用不到此指令。
iostat是I/O statistics（输入/输出统计）的缩写，用来动态监视系统的磁盘操作活动。
sar是System Activity Reporter（系统活动情况报告）的缩写。sar工具将对系统当前的状态进行取样，然后通过计算数据和比例来表达系统的当前运行状态。它的特点是可以连续对系统取样，获得大量的取样数据；取样数据和分析的结果都可以存入文件，所需的负载很小。sar是目前Linux上最为全面的系统性能分析工具之一，可以从14个大方面对系统的活动进行报告，包括文件的读写情况、系统调用的使用情况、串口、CPU效率、内存使用状况、进程活动及IPC有关的活动等，使用也是较为复杂。

参考资料:
http://www.shennongmin.org/?p=181
http://www.shennongmin.org/?p=176
http://www.cnblogs.com/mylinux/p/5836795.html
https://www.crifan.com/order_eabi_and_oabi/
http://www.bijishequ.com/detail/124277?p=