У нас есть проблема, связанная с приложением Java, работающим под (довольно старым) FC3 на плате Advantech POS с процессором Via C3. Приложение java имеет несколько скомпилированных разделяемых библиотек, доступ к которым осуществляется через JNI.
Через процессор C3 предполагается, что он совместим с i686. Некоторое время назад после установки Ubuntu 6.10 на плату MiniItx с тем же процессором я узнал, что предыдущий оператор не соответствует 100%. Ядро Ubuntu зависало при запуске из-за отсутствия некоторых конкретных и дополнительных инструкций i686, установленных в процессоре C3. Эти инструкции, отсутствующие в реализации C3 i686, используются по умолчанию компилятором GCC при использовании оптимизаций i686. Решение в этом случае состояло в том, чтобы перейти с i386 скомпилированной версией дистрибутива Ubuntu.
Основная проблема с приложением Java заключается в том, что дистрибутив FC3 был установлен на HD путем клонирования с изображения HD другого ПК, на этот раз Intel P4. После этого дистрибутивам необходимо было немного взломать его, например, заменить некоторые пакеты (например, ядро) на скомпилированную версию i383.
Проблема заключается в том, что после работы какое-то время система полностью висит без следа. Я боюсь, что некоторый код i686 оставлен где-то в системе и может быть выполнен случайным образом в любой момент (например, после восстановления из режима приостановки или что-то в этом роде).
Мой вопрос:
Я думаю, вам нужен инструмент, который проверяет каждую инструкцию, чтобы точно определить, к какому набору она принадлежит. Есть ли даже официальное название для конкретного набора инструкций, реализованных процессором C3? Если нет, это даже более волосатое.
Вариантом quick'n'dirty может быть необработанный поиск в файле, если вы можете определить бит-шаблон запрещенных инструкций. Просто проверьте их непосредственно, можно сделать, например, простой цепочкой objdump | grep.
Команда unix.linux 'file' отлично подходит для этого. Он может, как правило, определять целевую архитектуру и операционную систему для данного двоичного файла (и поддерживался с 1973 года. Wow!)
Конечно, если вы не работаете под UNIX/Linux, вы немного застряли. В настоящее время я пытаюсь найти порт на основе java, который я могу вызвать во время выполнения. Но такой удачи не было.
Команда unix 'file' предоставляет следующую информацию:
hex: ELF 32-разрядный исполняемый файл LSB, ARM, версия 1 (SYSV), динамически связанный (использует общие библиотеки), для GNU/Linux 2.4.17, не раздевается
Более подробную информацию о деталях архитектуры намекают на команду (unix) 'objdump -f', которая возвращает:
архитектура: рука, флаги 0x00000112: EXEC_P, HAS_SYMS, D_PAGED начальный адрес 0x0000876c
Этот исполняемый файл был скомпилирован кросс-компилятором gcc (скомпилирован на машине i86 для процессора ARM в качестве цели)
Я решил добавить еще одно решение для любого, кто пришел сюда: лично в моем случае информация, предоставленная 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 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
Чтобы ответить на неоднозначность того, является ли 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
Это работает даже для двоичных файлов.