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

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

Вопрос

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

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

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

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

Мой вопрос заключается в следующем:

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

Решение

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

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

Другие советы

В 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 в качестве целевого).

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

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

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

Чтобы ответить на двусмысленность того, является ли a 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 и предыдущие версии), затем с криками убегайте от него.Вы застрянете на медленном i386 / 486 Linux или вам придется перекомпилировать все свое программное обеспечение с оптимизацией, специфичной для Cyrix.

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

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

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

Самое быстрое, что можно найти в архитектуре, - это выполнить:

objdump -f testFile | grep architecture

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top