Determinar extensões alvo ISA de arquivo binário em Linux (biblioteca ou arquivo executável)

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

Pergunta

Nós temos um problema relacionado a um aplicativo Java executando sob uma (bastante antigo) FC3 em uma placa Advantech POS com um processador VIA C3. A aplicação Java tem vários compilado bibliotecas compartilhadas que são acessados ??via JNI.

processador

Via C3 é suposto ser i686 compatível. Há algum tempo depois de instalar o Ubuntu 6.10 em uma placa de MiniItx com o mesmo processador, eu descobri que a afirmação anterior não é 100% verdadeiro. O kernel do Ubuntu enforcado no arranque, devido à falta de algum específico e instruções opcionais do conjunto i686 no processador C3. Estas instruções ausentes na implementação C3 de conjunto i686 são usadas por padrão pelo compilador GCC ao usar i686 otimizações. A solução, neste caso, era para ir com uma versão i386 compilado da distribuição Ubuntu.

O problema de base com o aplicativo Java é que a distribuição FC3 foi instalado no HD por clonagem a partir de uma imagem do HD de outro PC, desta vez um processador Intel P4. Depois, a distribuição precisava de algum hacker para tê-lo em execução como a substituição de alguns pacotes (como o kernel) com a versão i386 compilado.

O problema é que, depois de trabalhar por um tempo completamente o sistema trava sem deixar vestígios. Tenho medo de que algum i686 código está em algum lugar à esquerda no sistema e pode ser executado de forma aleatória em qualquer altura (por exemplo, depois de se recuperar a partir do modo ou algo parecido suspender).

A minha pergunta é:

  • Existe alguma ferramenta ou maneira de descobrir em extensões de arquitetura que específicas de um arquivo binário (executável ou biblioteca) requer? file não dá informações suficientes.
Foi útil?

Solução

Eu acho que você precisa de uma ferramenta que verifica cada instrução, para determinar exatamente o que estabeleceu a que pertence. Existe até mesmo um nome oficial para o conjunto específico de instruções implementado pelo processador C3? Se não, é ainda mais peludo.

Uma variante quick'n'dirty poderia ser a de fazer uma pesquisa cru no arquivo, se você pode determinar o padrão das instruções não permitidos bit. teste só para eles diretamente, poderia ser feito por uma cadeia objdump | grep simples, por exemplo.

Outras dicas

O comando unix.linux file é ótimo para isso. É geralmente podem detectar a arquitetura alvo e sistema operacional para um determinado binário (e tem sido mantida dentro e fora desde 1973. wow!)

Claro que, se você não está sendo executado em Unix / Linux - você está um pouco preso. Atualmente estou tentando encontrar uma porta java base que eu possa chamar em tempo de execução .. mas não tive essa sorte.

O comando file unix dá informações 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

Informações mais detalhadas sobre os detalhes da arquitetura são insinuada com o (UNIX) objdump -f <fileName> que retorna: 

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

Este executável foi compilado por um compilador cruzado gcc (compiladas numa máquina i86 para o processador ARM como um alvo)

I decidir adicionar mais uma solução para o caso, que ficou aqui: pessoalmente, no meu caso as informações fornecidas pela file e objdump não foi suficiente, eo grep não é muito de uma ajuda - eu resolver o meu caso através do readelf -a -W.

Note, que este dá-lhe praticamente info. Os arco reside informação relacionada nas e o fim início. Aqui está um exemplo: 

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 ambigüidade de se um Via C3 é um processador de classe i686:. Não é, é um processador i586 classe

Cyrix nunca produziu um verdadeiro processador de 686 classe, apesar de suas reivindicações de marketing com as partes 6x86MX e MII. Entre outras instruções desaparecidos, dois mais importantes que eles não têm foram CMPXCHG8B e CPUID, que eram obrigados a executar o Windows XP e além.

National Semiconductor, AMD e VIA tem tudo CPU produzido design baseado na Cyrix 5x86 / 6x86 núcleo (NxP MediaGX, AMD Geode, VIA C3 / C7, VIA CoreFusion, etc.) que resultaram em excêntrico projeta onde você tem um 586 processador de classe com conjuntos / 2/3 de instrução SSE1.

A minha recomendação, se você se deparar com qualquer um dos CPUs listados acima e não é para um projeto de computador do vintage (ie. Windows 98SE e antes), em seguida, correr gritando longe dele. Você vai ser preso em lenta i386 / 486 Linux ou ter que recompilar todo o seu software com otimizações específicas Cyrix.

Expandindo resposta da @ Hi-Angel Eu encontrei uma maneira fácil de verificar a largura pouco de uma biblioteca estática: 

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

Onde libsomefile.a é a minha biblioteca estática. Deve trabalhar para outros arquivos ELF também.

mais rápida coisa para encontrar arquitetura seria para executar: 

objdump -f testFile | grep architecture

Isso funciona mesmo para binário.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top