Déterminer la cible ISA extensions du fichier binaire sous Linux (bibliothèque ou exécutable)
Nous avons un problème lié à une application Java exécutée sous un FC3 (plutôt ancien) sur une carte Advantech POS avec un processeur Via C3. L'application Java a plusieurs bibliothèques partagées compilées accessibles via JNI.
Le processeur Via C3 est censé ê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 facultatives du jeu i686 dans le processeur C3. Ces instructions manquantes dans l'implémentation C3 de l'ensemble i686 sont utilisées par défaut par le compilateur GCC lors de l'utilisation des optimisations i686. La solution, dans ce cas, consistait à opter pour une version compilée i386 de la distribution Ubuntu.
Le problème de base avec l'application Java est que la distribution FC3 a été installée sur le HD par clonage à partir d'une image du HD d'un autre PC, cette fois un Intel P4. Par la suite, la distribution a eu besoin de quelques le piratage pour le faire fonctionner, comme le remplacement de certains packages (comme celui du 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. J'ai peur que du code i686 soit laissé quelque part dans le système et puisse être exécuté de manière aléatoire à tout moment (par exemple après une récupération du mode suspension ou quelque chose comme ça).
Ma question est:
- Existe-t-il un outil ou un moyen de savoir de quelles extensions d'architecture spécifiques un fichier binaire (exécutable ou bibliothèque) a besoin?
filene donne pas suffisamment d'informations.
Je pense que vous avez besoin d'un outil qui vérifie chaque instruction, pour déterminer exactement à quel ensemble elle appartient. Existe-t-il même un nom officiel pour l'ensemble d'instructions spécifique implémenté par le processeur C3? Sinon, c'est encore plus poilu.
Une variante quick'n'dirty pourrait être de faire 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, cela pourrait être fait par un simple objdump | grep chaîne, par exemple.
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 il est maintenu sous et hors tension 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 à l'exécution .. mais pas de chance.
La commande unix file donne des informations comme ceci:
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 le (unix) objdump -f <fileName> commande qui retourne:
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 comme cible)
Je décide d'ajouter une autre solution pour tous ceux qui sont arrivés ici: personnellement, dans mon cas, les informations fournies par les file et objdump n'étaient pas suffisantes, et le grep n'est pas pas beaucoup d'aide - je résous mon cas par le readelf -a -W.
Notez que cela vous donne à peu près des informations. Les informations liées à Arch se trouvent au tout début et à la toute 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 une Via C3 est un processeur de classe i686: ce n'est pas le cas, c'est un processeur de classe i586.
Cyrix n'a jamais produit un véritable processeur de classe 686, malgré leurs prétentions marketing avec les pièces 6x86MX et MII. Parmi les autres instructions manquantes, deux importantes qu'elles n'avaient pas étaient CMPXCHG8b et CPUID, qui étaient nécessaires pour exécuter Windows XP et au-delà.
National Semiconductor, AMD et VIA ont tous produit des conceptions de CPU basées sur le noyau Cyrix 5x86/6x86 (NxP MediaGX, AMD Geode, VIA C3/C7, = VIA Corefusion, etc.) qui ont abouti à des conceptions bizarres où vous avez un processeur de classe 586 avec des 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 versions antérieures), exécutez-le en criant. Vous serez bloqué sur un i386/486 Linux lent ou devrez recompiler tous vos logiciels avec des optimisations spécifiques à Cyrix.
En développant la réponse de @ Hi-Angel, j'ai trouvé un moyen simple de vérifier la largeur de bits d'une bibliothèque statique:
readelf -a -W libsomefile.a | grep Class: | sort | uniq
Où libsomefile.a est ma bibliothèque statique. 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 le binaire.