web-dev-qa-db-ja.com

ターゲットを決定するISA Linuxのバイナリファイルの拡張子（ライブラリまたは実行可能ファイル）

Via C3プロセッサを搭載したAdvantech POSボード上の（やや古い）FC3で実行されているJavaアプリケーションに関連する問題があります。JavaアプリケーションはJNIを介してアクセスされるいくつかのコンパイル済み共有ライブラリ。

Via C3プロセッサはi686互換であると想定されています。しばらく前、同じプロセッサを搭載したMiniItxボードにUbuntu 6.10をインストールした後、前の声明が100％真実ではないことがわかりました。 Ubuntuカーネルは、C3プロセッサに設定されたi686の特定のオプションの指示がないため、起動時にハングしました。 i686セットのC3実装にないこれらの命令は、i686最適化の使用時にGCCコンパイラによってデフォルトで使用されます。この場合の解決策は、Ubuntuディストリビューションのi386コンパイルバージョンを使用することでした。

Javaアプリケーションの基本的な問題は、FC3ディストリビューションが別のPC（今回はIntel P4）のHDのイメージからクローンを作成することによってHDにインストールされたことです。一部のパッケージ（カーネルパッケージなど）をi386コンパイルバージョンに置き換えるなど、ハッキングして実行する。

問題は、しばらく作業した後、システムがトレースなしで完全にハングすることです。いくつかのi686コードがシステムのどこかに残っていて、いつでもランダムに実行される可能性があるのではないかと考えています（たとえば、サスペンドモードから回復した後など）。

私の質問は：

  • バイナリファイル（実行可能ファイルまたはライブラリ）に必要な特定のアーキテクチャ拡張機能を調べるツールまたは方法はありますか？ fileは十分な情報を提供しません。
linuxshared-librariesexecutablecpu-architectureinstruction-set
58
Fernando Miguélez

どの命令が属しているかを正確に判断するには、すべての命令をチェックするツールが必要だと思います。 C3プロセッサによって実装される特定の命令セットの正式名称もありますか？そうでない場合、それはさらに毛深いです。

許可されていない命令のビットパターンを判別できる場合、手っ取り早い方法としては、ファイル内で生の検索を行うことです。それらを直接テストするだけで、簡単なobjdump | grepチェーン、たとえば。

17
unwind

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プロセッサをターゲットとしてコンパイル））

106
Tim Kane

私はここに着いた人にもう1つのソリューションを追加することにしました：私の場合、fileとobjdumpによって提供される情報は十分ではなく、grepはあまり助けにはなりません-readelf -a -W。

これにより、ほとんどの情報が得られることに注意してください。 Arch関連の情報は最初と最後にあります。以下に例を示します。

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
29
Hi-Angel

Via C3がi686クラスのプロセッサであるかどうかの曖昧さに答えるには、そうではありません。i586クラスのプロセッサです。

Cyrixは、6x86MXおよびMIIパーツに関するマーケティング上の主張にもかかわらず、真の686クラスのプロセッサを製造しませんでした。他の欠落している命令の中で、彼らが持っていなかった2つの重要な命令はCMPXCHG8bとCPUIDであり、Windows XP以降を実行するために必要でした。

National Semiconductor、AMD、およびVIAは、Cyrix 5x86/6x86コア（NxP MediaGX、AMD Geode、VIA C3/C7、= VIA Corefusionなど）。これにより、SSE1/2/3命令セットを備えた586クラスのプロセッサを使用した奇数ボール設計が行われました。

上記のCPUのいずれかに出くわし、ビンテージコンピュータープロジェクト（Windows 98SE以前など）向けではない場合は、叫んで実行してください。遅いi386/486 Linuxで動けなくなるか、Cyrix固有の最適化ですべてのソフトウェアを再コンパイルする必要があります。

5
Duke

@ Hi-Angelの答えを拡張して、静的ライブラリのビット幅をチェックする簡単な方法を見つけました。

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

どこlibsomefile.aは私の静的ライブラリです。他のELFファイルでも機能するはずです。

4
jcoffland

アーキテクチャを見つけるための最も早いことは、実行することです。

objdump -f testFile | grep architecture

これはバイナリでも機能します。

3
Shailesh