Linuxのバイナリファイル（ライブラリまたは実行可能ファイル）のターゲットISA拡張を決定する
https://stackoverflow.com/questions/267941
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
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は十分な情報を提供しません。
解決
どのセットに属しているかを正確に判断するには、すべての命令をチェックするツールが必要だと思います。 C3プロセッサによって実装される特定の命令セットの正式名称もありますか？そうでない場合は、さらに毛深いです。
許可されていない命令のビットパターンを判別できる場合、quick'n'dirtyバリアントはファイル内で生の検索を行うことです。それらを直接テストするだけで、たとえば単純なobjdump | grepチェーンで実行できます。
他のヒント
unix.linux fileコマンドはこれに最適です。一般に、特定のバイナリのターゲットアーキテクチャとオペレーティングシステムを検出できます（1973年以降オンとオフが維持されています。すごい！）
もちろん、unix / linuxで実行していない場合は、少し立ち往生しています。現在、実行時に呼び出すことができるjavaベースのポートを探しています。しかし、そのような運はありません。
unix objdump -f <fileName>コマンドは、次のような情報を提供します。
hex: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped
アーキテクチャの詳細に関するより詳細な情報は、（unix）<=>コマンドを使用してヒントが示されます。
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000876c
この実行可能ファイルは、gccクロスコンパイラ（ターゲットとしてARMプロセッサのi86マシンでコンパイル）によってコンパイルされました
ここに来た人のためにもう1つのソリューションを追加することにしました：私の場合、個人的には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
Via C3がi686クラスのプロセッサであるかどうかの曖昧さに答えるには、そうではなく、i586クラスのプロセッサです。
Cyrixは、6x86MXおよびMIIパーツに関するマーケティング上の主張にもかかわらず、真の686クラスのプロセッサを製造しませんでした。他の欠落している指示の中で、彼らが持っていなかった2つの重要な指示は、Windows XP以降を実行するために必要なCMPXCHG8bとCPUIDでした。
National Semiconductor、AMD、およびVIAはすべて、Cyrix 5x86 / 6x86コア（NxP MediaGX、AMD Geode、VIA C3 / C7、VIA Corefusionなど）に基づいたCPU設計を作成しました。 SSE1 / 2/3命令セットを備えた586クラスのプロセッサ。
上記のCPUのいずれかに出くわし、ビンテージコンピュータープロジェクト（Windows 98SE以前）向けではない場合は、叫んで実行してください。遅いi386 / 486 Linuxで動けなくなるか、Cyrix固有の最適化ですべてのソフトウェアを再コンパイルする必要があります。
@ Hi-Angelの答えを拡大して、静的ライブラリのビット幅をチェックする簡単な方法を見つけました：
readelf -a -W libsomefile.a | grep Class: | sort | uniq
libsomefile.aは静的ライブラリです。他のELFファイルでも機能するはずです。
アーキテクチャを見つけるための最も簡単なことは、実行することです：
objdump -f testFile | grep architecture
これはバイナリでも機能します。
