Determinar el destino de ISA extensiones de archivo binario en Linux (biblioteca o archivo ejecutable)

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

Pregunta

Tenemos un problema relacionado con una aplicación Java que se ejecuta en un (viejo) FC3 en un Advantech POS de la junta con un procesador Via C3.La aplicación java tiene varios compilados de bibliotecas compartidas que se accede a través de JNI.

A través de C3 procesador se supone que i686 compatible.Hace algún tiempo después de instalar Ubuntu 6.10 en una MiniItx de la junta con el mismo procesador, me enteré de que la afirmación anterior no es 100% cierto.El kernel de Ubuntu colgado en el inicio debido a la falta de algunos específicos e instrucciones opcionales de la i686 establecido en el C3 del procesador.Estas instrucciones que faltan en C3 implementación de i686 conjunto se utilizan por defecto el compilador GCC cuando se utiliza i686 optimizaciones.La solución, en este caso, era ir con un i386 versión compilada de la distribución Ubuntu.

El problema de base con la aplicación Java es que el FC3 distribución fue instalado en el HD por clonación a partir de una imagen del HD de otra PC, esta vez de un Intel P4.Posteriormente, la distribución necesitaba un poco de hacking para poner en marcha tales como la sustitución de algunos paquetes (como el núcleo de uno) con el i386 versión compilada.

El problema es que después de trabajar durante un tiempo el sistema se bloquea completamente sin dejar rastro.Me temo que algunos i686 código se deja en algún lugar en el sistema y podría ser ejecutado de forma aleatoria en cualquier momento (por ejemplo después de la recuperación desde el modo de suspensión o algo así).

Mi pregunta es:

  • ¿Hay alguna herramienta o forma de averiguar en qué es lo específico de la arquitectura de las extensiones de archivo binario (ejecutable o una biblioteca) requiere? file no da suficiente información.
¿Fue útil?

Solución

Creo que necesita una herramienta que verifique cada instrucción, para determinar exactamente a qué conjunto pertenece. ¿Existe incluso un nombre oficial para el conjunto específico de instrucciones implementadas por el procesador C3? Si no, es aún más peludo.

Una variante rápida y sucia podría ser hacer una búsqueda sin procesar en el archivo, si puede determinar el patrón de bits de las instrucciones no permitidas. Simplemente pruebe para ellos directamente, podría hacerse mediante una simple cadena de objdump | grep, por ejemplo.

Otros consejos

El comando unix.linux file es excelente para esto. Generalmente puede detectar la arquitectura de destino y el sistema operativo para un binario determinado (y se ha mantenido encendido y apagado desde 1973. ¡guau!)

Por supuesto, si no está ejecutando bajo unix / linux, está un poco atascado. Actualmente estoy tratando de encontrar un puerto basado en Java al que pueda llamar en tiempo de ejecución ... pero no tuve suerte.

El comando unix objdump -f <fileName> proporciona información como esta: 

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

Se insinúa información más detallada sobre los detalles de la arquitectura con el comando (unix) <=> que devuelve: 

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

Este ejecutable fue compilado por un compilador cruzado gcc (compilado en una máquina i86 para el procesador ARM como destino)

Decido agregar una solución para todo, que tenemos aquí:personalmente en mi caso, la información proporcionada por el file y objdump no fue suficiente, y el grep no es una gran ayuda, puedo resolver mi caso a través de la readelf -a -W.

Tenga en cuenta, que esto le da bastante información.El arco relacionados con la información reside en el principio y el final.He aquí un ejemplo:

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

Para responder a la ambigüedad de si una Via C3 es un i686 clase de procesador:No, es una i586 procesador de clase.

Cyrix nunca se produjo una verdadera 686 procesador de clase, a pesar de sus reclamos de marketing con el 6x86MX y MII partes.Entre la falta de instrucciones, dos importantes no fueron CMPXCHG8b y CPUID, que fueron necesarios para ejecutar Windows XP y más allá.

National Semiconductor, AMD y VIA han presentado CPU diseños basados en el Cyrix 5x86/6x86 core (NxP MediaGX, AMD Geode, a TRAVÉS de C3/C7, a TRAVÉS de Corefusion, etc.) que se han traducido en el "bicho raro" de diseños de donde se tiene una 586 procesador de clase con SSE1/2/3 conjuntos de instrucciones.

Mi recomendación si usted viene a través de cualquiera de las Cpu mencionados anteriormente y no es para un vintage equipo del proyecto (es decir.Windows 98SE y antes), a continuación, salir corriendo lejos de él.Usted será atrapado en las lentas i386/486 Linux o tiene que volver a compilar todos los de su software con Cyrix optimizaciones específicas.

Ampliando la respuesta de @Hi-Angel, encontré una manera fácil de verificar el ancho de bits de una biblioteca estática: 

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

Donde libsomefile.a es mi biblioteca estática. Debería funcionar también para otros archivos ELF.

Lo más rápido para encontrar arquitectura sería ejecutar: 

objdump -f testFile | grep architecture

Esto funciona incluso para binario.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top