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

Question

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

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

Java应用程序的基本问题是通过克隆另一台PC的HD映像来安装在HD上的FC3发行版，这次是Intel P4。 之后，分发需要一些黑客才能让它运行，比如用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 -a -W 。

请注意，这可以为您提供相当多的信息。 拱形相关信息始于最开始和最后。 这是一个例子：

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处理器实现的特定指令集的官方名称？ 如果没有，它甚至更加毛茸茸。

如果您可以确定不允许的指令的位模式，那么quick'n'dirty变体可能是在文件中进行原始搜索。 只需直接测试它们，就可以通过一个简单的objdump | grep来完成 例如， objdump | grep链。

Answer 4

为了回答Via C3是否是i686级处理器的模糊性：它不是，它是i586级处理器。

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

美国国家半导体，AMD和VIA都生产了基于Cyrix 5x86 / 6x86核心（NxP MediaGX，AMD Geode，VIA C3 / C7，VIA Corefusion等）的CPU设计，这些设计导致了具有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

这甚至适用于二进制文件。