为Thumb或ARM编译的ARM ELF脚本/工具谓词

我有rootfs和klibc文件系统。我正在创建

make

规则，一些开发人员有一个没有联网的旧编译器。注1我试图验证所有文件是否仅在检测到编译器的特定版本时才使用arm生成。我已经重建了好几次这棵树。我正在使用

readelf-A

并寻找

Tag\u THUMB\u ISA\u use:THUMB-1

，但这似乎只存在于arm中的代码（但是使用交互编译器构建的）以及

THUMB

代码中。我可以手动运行

objdump-S

并检查汇编程序以确定正在使用的指令集

但是，如果我有一个脚本/工具谓词，那么使用

find

等可以搜索影子文件系统以查找可能丢失的二进制文件，就会容易得多。我原以为其中一些信息会出现在

ELF

标题中，可以通过

objdump

或

readelf

访问，但我没有发现任何可靠的信息

特别是我要找的,

编译的“C”如果没有

CONFIG\u ARM\u THUMB

Linux系统就无法运行

生成使用“C”编译器标志的规则，这些标志会阻塞非thumb编译器

---

注1:互通允许在

thumb

和

arm

模式之间轻松切换，编译器将自动生成代码以支持从任一模式调用。

因为thumb和arm序列可以在一个对象文件中自由交换，即使在同一节中，普通ELF头检查无法帮助您确定文件是否包含Thumb指令

---

一个稍微迂回但仍然不是100%简单的方法是使用

readelf-r

并检查输出是否包含“r\u ARM\u THM”，这表示拇指的重新定位。

readelf-A

输出没有描述elf内容。它只描述了处理器和/或系统的功能，这些功能是预期的或提供给编译器的。由于我有一个

ARM926

CPU，它是一个

ARMV5TEJ

处理器，gcc/ld将始终设置

Tag\u THUMB\u ISA\u use:THUMB-1

，因为它只是意味着

ARMV5TEJ

被认为具有

THUMB-1

功能。它没有说明代码本身

检查Linux例程

elf\u check\u arch（）

显示对

x->e\u entry&1的检查。这将导致以下脚本

readelf -h $1 | grep -q Entry.*[13579bdf]$

也就是说，只需查看初始的ELF输入值，看看是否设置了低位。这是一个快速检查，符合我所寻找的精神。任何ELF中的代码都可以混合和匹配ARM和Thumb。如果程序动态地标识CPU并选择适当的例程，这可能是正常的。也就是说，仅仅存在Thumb指令并不意味着代码将被执行

只需查看
条目
值就可以确定使用了哪些
gcc
编译器标志，至少对于
gcc
4.6到4.7版是这样。
这很有用，我考虑了“手臂或拇指”问题。我想我想知道它是否是为Thumb编译的；我没想到会有手工编码的汇编程序<代码>用于i in*；do readelf-r$i | grep-q‘不搬迁’| | echo$i；完成

对klibc不返回任何内容。我猜他们没有任何重新定位，这将加快加载速度。这个答案告诉您是否使用了

gcc-mthumb

或类似的方法。我们总是可以混合指令集（这就是inter networking的意义），但条目将是编译器使用的主要模式。理论上，编译器可以生成这两种类型的指令，但通常不会。