確定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

這甚至適用於二進制文件。