3

我有rootfs和klibc文件系统。我正在创建make规则，一些开发人员有一个没有联网的旧编译器。note1 我正在尝试验证是否只有在检测到特定版本的编译器时才使用arm构建所有文件。我已经多次重建了这棵树。我正在使用readelf -A和寻找Tag_THUMB_ISA_use: Thumb-1，但这似乎是仅在arm代码（但使用互通编译器构建）以及thumb代码。我可以手动运行objdump -S并检查汇编程序以确定正在使用的指令集。

但是，如果我有一个脚本/工具谓词，这样会更容易，这样find就可以使用 , etc 来搜索影子文件系统以查找可能丢失的二进制文件。我认为其中一些信息会在ELF标题中，并且可以通过objdumpor访问readelf，但我没有找到任何可靠的信息。

具体来说，我正在寻找，

  1. CONFIG_ARM_THUMB编译的“C”在没有Linux 系统的情况下无法运行。
  2. make使用“C”编译器标志的规则会阻塞非拇指编译器。

注意1：thumb互通允许在和模式之间轻松切换arm，编译器将自动生成代码以支持从任一模式调用。

4

2 回答 2

4

readelf -A输出没有描述精灵的内容。它只是描述了处理器和/或系统的能力，这些能力是预期的或提供给编译器的。由于我有一个作为处理器的ARM926CPU ARMV5TEJ，gcc/ld 将始终设置Tag_THUMB_ISA_use: Thumb-1为它只是意味着它ARMV5TEJ被认为是有Thumb-1能力的。它没有说明代码本身。

检查 Linux arch/arm/kernel/elf.c例程elf_check_arch()显示检查x->e_entry & 1. 这导致以下脚本，

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

即，只需查看初始ELF条目值并查看是否设置了低位。这是一个快速检查，符合我正在寻找的精神。 unixsmurf有一个优点，即任何ELF中的代码都可以混合和匹配ARM和Thumb。如果程序动态识别CPU 并选择适当的例程，这可能没问题。即，仅存在Thumb指令并不意味着该代码将执行。

只需查看该entry值就可以确定使用了哪些gcc编译器标志，至少对于gcc4.6 到 4.7 版本。

于 2013-04-10T16:19:27.917 回答
3

由于拇指和手臂序列可以在目标文件中自由互换，即使在同一部分中，简单的 ELF 标头检查也无法帮助您确定文件是否包含 Thumb 指令。

一个稍微迂回但仍然不是 100% 万无一失的方法是使用readelf -r并检查输出是否包含“R_ARM_THM”，表示拇指的重定位。

于 2013-04-10T12:12:05.037 回答