Déterminer les extensions ISA cibles du fichier binaire sous Linux (bibliothèque ou exécutable)

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

Question

Nous avons un problème lié à une application Java exécutée sous un FC3 (plutôt ancien) sur une carte de point de vente Advantech avec un processeur Via C3. L’application Java possède plusieurs bibliothèques partagées compilées accessibles via JNI.

Le processeur Via C3 est supposé être compatible i686. Il y a quelque temps, après avoir installé Ubuntu 6.10 sur une carte MiniItx avec le même processeur, j'ai découvert que la déclaration précédente n'était pas vraie à 100%. Le noyau Ubuntu a été suspendu au démarrage en raison de l'absence d'instructions spécifiques et optionnelles de l'i686 défini dans le processeur C3. Ces instructions manquantes dans l'implémentation C3 du jeu i686 sont utilisées par défaut par le compilateur GCC lors de l'utilisation des optimisations i686. Dans ce cas, la solution consistait à utiliser une version compilée i386 de la distribution Ubuntu.

Le problème de base de l'application Java est que la distribution FC3 a été installée sur le disque dur par clonage à partir d'une image du disque dur d'un autre PC, cette fois un processeur Intel P4. Par la suite, la distribution avait besoin de piratage pour pouvoir fonctionner, par exemple en remplaçant certains paquets (comme le noyau) par la version compilée i386.

Le problème est qu’après avoir travaillé pendant un certain temps, le système se bloque complètement sans laisser de trace. Je crains que du code i686 ne soit laissé quelque part dans le système et puisse être exécuté de manière aléatoire à tout moment (par exemple, après la sortie du mode suspension ou quelque chose du genre).

Ma question est la suivante:

  • Existe-t-il un outil ou un moyen de savoir à quelles extensions d'architecture spécifiques un fichier binaire (exécutable ou bibliothèque) a besoin? file ne donne pas assez d'informations.
Était-ce utile?

La solution

Je pense que vous avez besoin d’un outil qui vérifie chaque instruction afin de déterminer le jeu auquel elle appartient. Existe-t-il même un nom officiel pour l'ensemble d'instructions spécifiques implémentées par le processeur C3? Sinon, c'est encore plus poilu.

Une variante quick'n'dirty pourrait consister à effectuer une recherche brute dans le fichier, si vous pouvez déterminer le modèle de bits des instructions non autorisées. Il suffit de les tester directement, par exemple avec une simple objdump | grep chaîne.

Autres conseils

La commande unix.linux file est idéale pour cela. Il peut généralement détecter l’architecture cible et le système d’exploitation pour un binaire donné (et est maintenu allumé et éteint depuis 1973. wow!)

Bien sûr, si vous ne travaillez pas sous unix / linux, vous êtes un peu coincé. J'essaie actuellement de trouver un port basé sur Java que je peux appeler au moment de l'exécution .. mais pas de chance.

La commande unix objdump -f <fileName> fournit des informations telles que: 

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

Des informations plus détaillées sur les détails de l'architecture sont indiquées avec la commande (unix) <=> qui renvoie: 

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

Cet exécutable a été compilé par un compilateur croisé gcc (compilé sur une machine i86 pour le processeur ARM en tant que cible)

Je décide d'ajouter une solution supplémentaire à tous ceux qui sont arrivés ici: personnellement, les informations fournies par file et objdump ne suffisaient pas, et grep n'était pas très utile. - Je résous mon cas via le readelf -a -W.

Notez que cela vous donne pas mal d’informations. Les informations relatives à l’architecture résident au tout début et à la fin. Voici un exemple: 

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

Pour répondre à l’ambiguïté de savoir si un Via C3 est un processeur de classe i686: ce n’est pas un processeur de classe i586.

Cyrix n’a jamais produit de véritable processeur de classe 686, malgré leurs prétentions marketing avec les composants 6x86MX et MII. CMPXCHG8b et CPUID, entre autres instructions manquantes, étaient indispensables à l’exécution de Windows XP et des versions ultérieures.

National Semiconductor, AMD et VIA ont tous mis au point des conceptions de CPU basées sur le cœur Cyrix 5x86 / 6x86 (NxP MediaGX, AMD Geode, VIA C3 / C7, VIA Corefusion, etc.), ce qui a donné lieu à des conceptions inhabituelles. Processeur de classe 586 avec jeux d'instructions SSE1 / 2/3.

Ma recommandation si vous rencontrez l'un des processeurs répertoriés ci-dessus et que ce n'est pas pour un projet d'ordinateur vintage (c'est-à-dire Windows 98SE et les versions antérieures) est alors lancée en hurlant. Vous serez bloqué sous Linux lent i386 / 486 ou devrez recompiler l’ensemble de vos logiciels avec les optimisations spécifiques à Cyrix.

En développant la réponse de @ Hi-Angel, j'ai trouvé un moyen simple de vérifier la largeur en bits d'une bibliothèque statique: 

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

Où libsomefile.a est ma bibliothèque statique. Cela devrait également fonctionner pour d’autres fichiers ELF.

La chose la plus rapide pour trouver une architecture serait d'exécuter: 

objdump -f testFile | grep architecture

Cela fonctionne même pour les programmes binaires.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top