确定 Linux 中二进制文件的目标 ISA 扩展名（库或可执行文件）

Question

我们遇到一个与在具有 Via C3 处理器的 Advantech POS 板上（相当旧的）FC3 下运行的 Java 应用程序相关的问题。 java 应用程序有几个已编译的共享库，可以通过 JNI 访问。

Via C3 处理器应该与 i686 兼容。前段时间在具有相同处理器的MiniItx板上安装Ubuntu 6.10后，我发现之前的说法并不是100%正确。由于缺少 C3 处理器中 i686 集的一些特定和可选指令，Ubuntu 内核在启动时挂起。在使用 i686 优化时，GCC 编译器默认使用 i686 集的 C3 实现中缺少的这些指令。在这种情况下，解决方案是使用 Ubuntu 发行版的 i386 编译版本。

Java 应用程序的基本问题是 FC3 发行版是通过从另一台 PC（这次是 Intel P4）的 HD 映像克隆来安装在 HD 上的。之后，该发行版需要进行一些修改才能使其运行，例如用 i386 编译版本替换一些软件包（例如内核软件包）。

问题是，工作一段时间后，系统完全挂起，不留痕迹。我担心某些 i686 代码会留在系统中的某个位置，并且可以随时随机执行（例如从挂起模式恢复后或类似的情况）。

我的问题是：

• 是否有任何工具或方法可以找出二进制文件（可执行文件或库）需要哪些特定的体系结构扩展？

  file

  没有提供足够的信息。

Answer 1

unix.linux

file

命令非常适合此操作。它通常可以检测给定二进制文件的目标架构和操作系统（并且自 1973 年以来一直保持断断续续。哇！）

当然，如果你不是在 unix/linux 下运行 - 你就会有点卡住了。我目前正在尝试找到一个可以在运行时调用的基于 java 的端口..但没有这样的运气。

unix

file

命令提供如下信息：

hex: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped

有关架构细节的更多详细信息通过 (unix)

objdump -f <fileName>

命令提示，该命令返回：

architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000876c

此可执行文件由 gcc 交叉编译器编译（在 i86 机器上以 ARM 处理器为目标进行编译）

Answer 2

就我而言，

file

和

objdump

提供的信息还不够，

grep

也没有任何帮助。

有效的是：

readelf -a -W

。它输出很多信息。与拱门相关的信息位于最开始和最后。这是一个例子：

λ readelf -aW ./my_binary
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:                           ARM
  Version:                           0x1
  Entry point address:               0x83f8
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2388 (bytes into file)
  Flags:                             0x5000202, has entry point, Version5 EABI, soft-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         31
  Section header string table index: 28
[…]
Displaying notes found at file offset 0x00000148 with length 0x00000020:
  Owner                 Data size   Description
  GNU                  0x00000010   NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.16
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_CPU_unaligned_access: v6

Answer 3

我认为您需要一个工具来检查每条指令，以准确确定它属于哪个集合。 C3 处理器实现的特定指令集是否有正式名称？如果没有的话，它的毛就更多了。

如果您可以确定不允许的指令的位模式，则一种快速而肮脏的变体可能是在文件中进行原始搜索。只需直接测试它们，例如可以通过简单的

objdump | grep

链来完成。

Answer 4

回答 Via C3 是否是 i686 级处理器的歧义：不是，它是 i586 级处理器。

Cyrix 从未生产过真正的 686 级处理器，尽管他们在营销中声称使用 6x86MX 和 MII 部件。在其他缺失的指令中，他们没有的两个重要指令是 CMPXCHG8b 和 CPUID，这是运行 Windows XP 及更高版本所必需的。

National Semiconductor、AMD 和 VIA 都生产了基于 Cyrix 5x86/6x86 核心的 CPU 设计（NxP MediaGX、AMD Geode、VIA C3/C7、VIA Corefusion 等），这导致了 586 级的奇怪设计具有 SSE1/2/3 指令集的处理器。

我的建议是，如果您遇到上面列出的任何 CPU，并且它不适合老式计算机项目（即 Windows 98SE 及更早版本），请立即远离它。您将被困在缓慢的 i386/486 Linux 上，或者必须使用 Cyrix 特定的优化重新编译所有软件。

Answer 5

扩展@Hi-Angel的答案，我找到了一种检查静态库位宽度的简单方法：

readelf -a -W libsomefile.a | grep Class: | sort | uniq

其中

libsomefile.a

是我的静态库。也应该适用于其他 ELF 文件。

Answer 6

找到架构最快的事情就是执行：

objdump -f testFile | grep architecture

这甚至适用于二进制。