Определить целевые расширения ISA двоичного файла в Linux (библиотека или исполняемый файл)

Question

У нас есть проблема, связанная с Java-приложением, работающим под (довольно старым) FC3 на POS-плате Advantech с процессором Via C3. В приложении java есть несколько скомпилированных общих библиотек, доступ к которым осуществляется через JNI.

Через процессор C3 предполагается совместимость с i686. Некоторое время назад после установки Ubuntu 6.10 на плате MiniItx с тем же процессором я обнаружил, что предыдущее утверждение не на 100% верно. Ядро Ubuntu зависало при запуске из-за отсутствия некоторых специальных и дополнительных инструкций для i686, установленных в процессоре C3. Эти инструкции, отсутствующие в реализации C3 набора i686, по умолчанию используются компилятором GCC при использовании оптимизаций i686. В данном случае решением было использовать скомпилированную версию дистрибутива Ubuntu для i386.

Основная проблема с приложением Java состоит в том, что дистрибутив FC3 был установлен на HD путем клонирования из образа HD другого ПК, на этот раз Intel P4. После этого дистрибутиву потребовался некоторый взлом для его запуска, например, замена некоторых пакетов (например, ядра) на скомпилированную версию i386.

Проблема в том, что после некоторой работы система полностью зависает без следа. Я боюсь, что некоторый код i686 остался где-то в системе и мог быть выполнен случайным образом в любое время (например, после восстановления из режима ожидания или чего-то в этом роде).

Мой вопрос:

• Существует ли какой-либо инструмент или способ узнать, для каких конкретных расширений архитектуры требуется бинарный файл (исполняемый файл или библиотека)? file не дает достаточно информации.

Answer 1

Команда unix.linux file отлично подходит для этого. Как правило, он может определять целевую архитектуру и операционную систему для данного двоичного файла (и поддерживается и выключается с 1973 года. Вау!)

Конечно, если вы не работаете под Unix / Linux - вы немного застряли. В настоящее время я пытаюсь найти порт на основе Java, который я могу вызвать во время выполнения ... но не повезло.

Команда unix file дает такую ​​информацию:

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

Более подробная информация о деталях архитектуры указывается с помощью команды (unix) objdump -f <fileName>, которая возвращает:

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

Этот исполняемый файл был скомпилирован кросс-компилятором gcc (скомпилирован на машине i86 для процессора ARM в качестве цели)

Answer 2

Я решил добавить еще одно решение для всех, кто сюда попал: лично в моем случае информации, предоставленной file и objdump, было недостаточно, а grep не сильно помогает - Я разрешаю дело через readelf -a -W.

Обратите внимание, что это дает вам довольно много информации. Информация, связанная с аркой, находится в самом начале и в самом конце. Вот пример:

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

Answer 3

Я думаю, вам нужен инструмент, который проверяет каждую инструкцию, чтобы точно определить, к какому набору она принадлежит. Есть ли даже официальное название для конкретного набора инструкций, реализованных процессором C3? Если нет, то это даже волосатее.

Быстрый и грязный вариант может заключаться в необработанном поиске в файле, если вы можете определить битовую комбинацию запрещенных команд. Просто проверьте их напрямую, например, с помощью простой цепочки objdump | grep.

Answer 4

Чтобы ответить на неоднозначность того, является ли Via C3 процессором класса i686: это не так, это процессор класса i586.

Cyrix никогда не производила настоящий процессор класса 686, несмотря на свои маркетинговые претензии с частями 6x86MX и MII. Среди других недостающих инструкций две важные из них, которых у них не было, были CMPXCHG8b и CPUID, которые были необходимы для запуска Windows XP и более поздних версий.

National Semiconductor, AMD и VIA разработали процессоры на базе ядра Cyrix 5x86 / 6x86 (NxP MediaGX, AMD Geode, VIA C3 / C7, VIA Corefusion и т. Д.), Что привело к созданию странных конструкций, в которых у вас есть Процессор класса 586 с наборами команд SSE1 / 2/3.

Моя рекомендация, если вы столкнетесь с любым из процессоров, перечисленных выше, и это не для проекта старинного компьютера (например, Windows 98SE и более ранних версий), тогда бегите, крича от него. Вы застрянете на медленном Linux i386 / 486 или вам придется перекомпилировать все свое программное обеспечение с помощью специфических для Cyrix оптимизаций.

Answer 5

Расширяя ответ @ Hi-Angel, я нашел простой способ проверить битовую ширину статической библиотеки:

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

Где libsomefile.a - моя статическая библиотека. Должно работать и для других файлов ELF.

Answer 6

Быстрее всего найти архитектуру:

objdump -f testFile | grep architecture

Это работает даже для двоичного файла.