确定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.

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

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链来完成.

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的优化重新编译所有软件.