Determinare le estensioni ISA di destinazione del file binario in Linux (libreria o file eseguibile)

StackOverflow https://stackoverflow.com/questions/267941

Domanda

Si è verificato un problema relativo a un'applicazione Java in esecuzione su un (piuttosto vecchio) FC3 su una scheda POS Advantech con un processore Via C3. L'applicazione java ha diverse librerie condivise compilate a cui si accede tramite JNI.

Il processore via C3 dovrebbe essere compatibile con i686. Qualche tempo fa dopo aver installato Ubuntu 6.10 su una scheda MiniItx con lo stesso processore, ho scoperto che la precedente dichiarazione non è vera al 100%. Il kernel di Ubuntu si è bloccato all'avvio a causa della mancanza di alcune istruzioni specifiche e opzionali del set i686 nel processore C3. Queste istruzioni mancanti nell'implementazione C3 del set i686 vengono utilizzate per impostazione predefinita dal compilatore GCC quando si utilizzano le ottimizzazioni i686. La soluzione, in questo caso, era quella di utilizzare una versione compilata i386 della distribuzione Ubuntu.

Il problema di base con l'applicazione Java è che la distribuzione FC3 è stata installata sull'HD clonando da un'immagine dell'HD di un altro PC, questa volta un Intel P4. Successivamente, la distribuzione aveva bisogno di alcuni hacking per averlo in esecuzione, come la sostituzione di alcuni pacchetti (come quello del kernel) con la versione compilata i386.

Il problema è che dopo aver lavorato per un po 'il sistema si blocca completamente senza lasciare traccia. Temo che un po 'di codice i686 sia lasciato da qualche parte nel sistema e possa essere eseguito in modo casuale in qualsiasi momento (ad esempio dopo il ripristino dalla modalità di sospensione o qualcosa del genere).

La mia domanda è:

  • Esiste uno strumento o un modo per scoprire quali specifiche estensioni dell'architettura richiede un file binario (eseguibile o libreria)? file non fornisce informazioni sufficienti.
È stato utile?

Soluzione

Penso che tu abbia bisogno di uno strumento che controlli ogni istruzione, per determinare esattamente a quale set appartiene. Esiste persino un nome ufficiale per l'insieme specifico di istruzioni implementato dal processore C3? Altrimenti, è ancora più peloso.

Una variante quick'n'dirty potrebbe essere quella di eseguire una ricerca grezza nel file, se è possibile determinare il modello di bit delle istruzioni non consentite. Basta testarli direttamente, potrebbe essere fatto da una semplice objdump | grep catena, per esempio.

Altri suggerimenti

Il comando unix.linux file è ottimo per questo. In genere è in grado di rilevare l'architettura di destinazione e il sistema operativo per un determinato file binario (ed è stato attivato e disattivato dal 1973. wow!)

Ovviamente, se non stai eseguendo unix / linux, sei un po 'bloccato. Attualmente sto cercando di trovare una porta basata su Java che posso chiamare in fase di runtime .. ma senza fortuna.

Il comando unix objdump -f <fileName> fornisce informazioni come questa: 

hex: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped

Informazioni più dettagliate sui dettagli dell'architettura sono suggerite con il comando (unix) <=> che restituisce: 

architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000876c

Questo eseguibile è stato compilato da un compilatore cross gcc (compilato su una macchina i86 per il processore ARM come destinazione)

Decido di aggiungere un'altra soluzione per chi è arrivato qui: personalmente nel mio caso le informazioni fornite da file e objdump non erano sufficienti e grep non è di grande aiuto - Risolvo il mio caso tramite readelf -a -W.

Nota che questo ti dà praticamente molte informazioni. Le informazioni relative all'arco risiedono all'inizio e alla fine. Ecco un esempio: 

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

Per rispondere all'ambiguità del fatto che un Via C3 sia un processore di classe i686: non lo è, è un processore di classe i586.

Cyrix non ha mai prodotto un vero processore di classe 686, nonostante le sue affermazioni sul marketing con le parti 6x86MX e MII. Tra le altre istruzioni mancanti, due importanti che non avevano erano CMPXCHG8b e CPUID, necessari per eseguire Windows XP e oltre.

National Semiconductor, AMD e VIA hanno prodotto tutti i progetti CPU basati sul core Cyrix 5x86 / 6x86 (NxP MediaGX, AMD Geode, VIA C3 / C7, VIA Corefusion, ecc.) che hanno portato a progetti strani in cui hai un Processore 586 con set di istruzioni SSE1 / 2/3.

La mia raccomandazione se ti imbatti in una delle CPU sopra elencate e non è per un progetto di computer vintage (cioè Windows 98SE e precedenti), allora corri via da esso. Sarai bloccato su Linux i386 / 486 lento o dovrai ricompilare tutto il tuo software con ottimizzazioni specifiche di Cyrix.

Espandendo la risposta di @ Hi-Angel, ho trovato un modo semplice per controllare la larghezza dei bit di una libreria statica: 

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

Dove libsomefile.a è la mia libreria statica. Dovrebbe funzionare anche per altri file ELF.

La cosa più veloce per trovare l'architettura sarebbe eseguire: 

objdump -f testFile | grep architecture

Funziona anche per binario.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top