Войти
A Жирный двоичный (или многоархитектурный двоичный ) - это компьютерная исполняемая программа или библиотека, которая была расширена (или «расширена») кодом, присущим множеству наборов инструкций, которые, следовательно, могут быть запущены на несколько типов процессоров. В результате получается файл большего размера, чем обычный двоичный файл с одной архитектурой, отсюда и имя.
Обычный метод реализации состоит в том, чтобы включить версию машинного кода для каждого набора команд, которому предшествует единственная точка входа с кодом, совместимым со всеми операционными системами., который выполняет переход в соответствующий раздел. Альтернативные реализации хранят разные исполняемые файлы в разных ответвлениях , каждый со своей собственной точкой входа, которая напрямую используется операционной системой.
Использование толстых двоичных файлов не является распространенным в программном обеспечении операционной системы ; есть несколько альтернатив для решения той же проблемы, например, использование программы installer для выбора архитектурно-зависимого двоичного файла во время установки (например, с Android несколькими APK), выбрав архитектурно-зависимый двоичный файл во время выполнения (например, с объединенными каталогами Plan 9 и толстыми пакетами GNUstep ), распространение программного обеспечения в форме исходного кода и компиляция на месте или использование виртуальной машины (например, с Java ) и компиляция Just In Time.
В 1988 году Apollo Computer домен / ОС SR10.1 представил новый тип файла, "cmpexe" (составной исполняемый файл), который объединял двоичные файлы для Motorola 680x0 и Apollo PRISM исполняемых файлов.
Жирно-двоичная схема сгладила переход Apple Macintosh, начавшийся в 1994 году, с 68k микропроцессоров на PowerPC микропроцессоры. Многие приложения для старой платформы прозрачно выполнялись на новой платформе в рамках развивающейся схемы эмуляции, но эмулируемый код обычно работает медленнее, чем собственный код. Приложения, выпущенные как «толстые двоичные файлы», занимали больше места для хранения, но они работали на полной скорости на любой платформе. Это было достигнуто путем упаковки скомпилированной версии 68000 и версии одной и той же программы, скомпилированной на PowerPC, в их исполняемые файлы. Старый код 68K (CFM-68K или классический 68K) продолжал храниться в ответвлении ресурсов , в то время как новый код PowerPC содержался в ответвлении данных, в PEF. format.
Жирные двоичные файлы были больше, чем программы, поддерживающие только PowerPC или 68k, что привело к созданию ряда утилит, которые удаляли ненужную версию. В эпоху маленьких жестких дисков, когда жесткие диски 80 МБ были обычным размером, эти утилиты иногда были полезны, так как программный код обычно составлял большой процент от общего использования диска, и удаление ненужных элементов толстый двоичный файл освободит значительный объем места на жестком диске.
Жирные бинарные файлы были особенностью NeXT NeXTSTEP / OPENSTEP, начиная с NeXTSTEP 3.1. В NeXTSTEP они назывались «бинарными файлами с множественной архитектурой». Изначально двоичные файлы с несколькими архитектурами были предназначены для компиляции программного обеспечения для работы как на аппаратном обеспечении NeXT Motorola 68k, так и на компьютерах на базе Intel IA-32 с запущенным NeXTSTEP, с одним двоичный файл для обеих платформ. Позже он использовался для запуска приложений OPENSTEP на ПК и различных поддерживаемых OPENSTEP платформ RISC. Мультиархитектурные двоичные файлы находятся в специальном архивном формате, в котором один файл хранит один или несколько субфайлов Mach-O для каждой архитектуры, поддерживаемой многоархитектурным двоичным файлом. Каждый мультиархитектурный двоичный файл начинается со структуры (struct fat_header), содержащей два целых числа без знака. Первое целое число («магическое») используется как магическое число, чтобы идентифицировать этот файл как Fat Binary. Второе целое число («nfat_arch») определяет, сколько файлов Mach-O содержится в архиве (сколько экземпляров одной и той же программы для разных архитектур). После этого заголовка идет nfat_arch количество структур fat_arch (struct fat_arch). Эта структура определяет смещение (от начала файла), по которому следует найти файл, выравнивание, размер, а также тип и подтип ЦП, на которые нацелен двоичный файл Mach-O (в архиве).
Версия GNU Compiler Collection, поставляемая с инструментами разработчика, могла кросс-компилировать исходный код для различных архитектур, на которых NeXTStep Бежать смог. Например, можно было выбрать целевые архитектуры с несколькими опциями «-арх» (с архитектурой в качестве аргумента). Это был удобный способ распространения программы для NeXTStep, работающей на разных архитектурах.
Также было возможно создавать библиотеки (например, используя libtool) с разными целевыми объектными файлами.
Apple Computer приобрела NeXT в 1996 году и продолжала работать с кодом OPENSTEP. Mach-O стал собственным форматом объектных файлов в бесплатной Darwin операционной системе от Apple (2000) и Apple Mac OS X (2001), а мультиархитектурные двоичные файлы NeXT продолжали поддерживаться операционная система. В Mac OS X многоархитектурные бинарные файлы могут использоваться для поддержки нескольких вариантов архитектуры, например, чтобы иметь разные версии 32-битного кода, оптимизированного для PowerPC G3, PowerPC G4 и PowerPC 970 поколения процессоров. Его также можно использовать для поддержки нескольких архитектур, таких как 32-разрядная и 64-разрядная PowerPC или PowerPC и x86.
Логотип Apple Universal binary В В 2005 году Apple объявила об очередном переходе с процессоров PowerPC на процессоры Intel x86. Apple способствовала распространению новых приложений, которые изначально поддерживают PowerPC и x86, используя исполняемые файлы в многоархитектурном двоичном формате. Apple называет такие программы «Универсальные приложения » и называет формат файла «Универсальный двоичный код » как, возможно, способ отличить этот новый переход от предыдущего перехода или других применений мультиархитектуры. Двоичный формат.
Универсальный двоичный формат не требовался для прямой миграции ранее существовавших собственных приложений PowerPC; с 2006 по 2011 год Apple поставила Rosetta, динамический двоичный преобразователь PowerPC (PPC) в x86 , чтобы играть эту роль. Однако у Rosetta были довольно большие накладные расходы на производительность, поэтому разработчикам было рекомендовано предлагать двоичные файлы как PPC, так и Intel, используя универсальные двоичные файлы. Очевидная стоимость универсального двоичного файла заключается в том, что каждый установленный исполняемый файл больше, но за годы, прошедшие после выпуска PPC, место на жестком диске значительно превысило размер исполняемого файла; в то время как универсальный двоичный файл может быть вдвое больше одноплатформенной версии того же приложения, ресурсы свободного пространства обычно затмевают размер кода, что становится незначительной проблемой. Фактически, часто универсально-двоичное приложение будет меньше двух приложений с одной архитектурой, потому что программные ресурсы могут совместно использоваться, а не дублироваться. Если требуются не все архитектуры, приложения командной строки lipo и ditto могут использоваться для удаления версий из двоичного образа с несколькими архитектурами, создавая тем самым то, что иногда называют тонким двоичным файлом.
Кроме того, двоичные исполняемые файлы с несколькими архитектурами могут содержать код как для 32-битных, так и для 64-битных версий PowerPC и x86, что позволяет поставлять приложения в форме, поддерживающей 32-битные процессоры, но использующей большего адресного пространства и более широких путей к данным при работе на 64-битных процессорах.
В версиях среды разработки Xcode от 2.1 до 3.2 (работает на Mac OS X 10.4 через Mac OS X 10.6 ), Apple включены служебные программы, которые позволяют использовать приложения как для архитектуры Intel, так и для PowerPC; универсальные двоичные файлы в конечном итоге могут содержать до четырех версий исполняемого кода (32-разрядный PowerPC, 32-разрядный x86, 64-разрядный PowerPC и 64-разрядный x86 ). Однако поддержка PowerPC была удалена из Xcode 4.0 и поэтому недоступна для разработчиков, использующих Mac OS X 10.7 или выше.
В 2020 году Apple объявила об очередном переходе , на этот раз с процессоров Intel x86 на кремниевые микросхемы Apple. Чтобы сгладить переход, Apple добавила поддержку двоичного формата Universal 2. Это позволяет создавать двоичные файлы, которые изначально работают как на 64-битной микросхеме Intel, так и на 64-битной микросхеме Apple (вариант Aarch64 ).
CP / M-80, MP / M-80, Параллельные исполняемые файлы CP / M, CP / M Plus и Personal CP / M-80 для Intel 8080 (и Z80 ) семейства процессоров используют то же расширение файла .COM , что и DOS -совместимые операционные системы для двоичных файлов Intel 8086. В обоих случаях программы загружаются со смещением + 100h и выполняются путем перехода к первому байту файла. Поскольку коды операций двух семейств процессоров несовместимы, попытка запустить программу в неправильной операционной системе приводит к неправильному и непредсказуемому поведению.
Чтобы избежать этого, были разработаны некоторые методы для создания толстых двоичных файлов, которые содержат как CP / M-80, так и программу DOS, которой предшествует исходный код, который правильно интерпретируется на обеих платформах. Эти методы либо объединяют две полнофункциональные программы, каждая из которых создана для соответствующей среды, либо добавляют заглушки, которые заставляют программу корректно завершаться, если она запущена на неправильном процессоре. Чтобы это работало, первые несколько инструкций в файле.COM должны быть допустимым кодом для процессоров 8086 и 8080, что приведет к переходу процессоров в разные места в коде. Например, утилиты в эмуляторе Симеона Крана MyZ80 начинаются с последовательности кода операции EBh, 52h, EBh. 8086 воспринимает это как скачок и читает свою следующую инструкцию со смещения + 154h, тогда как 8080 или совместимый процессор проходит напрямую и читает свою следующую инструкцию с + 103h. Для этой цели используется аналогичная последовательность: EBh, 03h, C3h.
Другой метод предотвращения ошибочного выполнения DOS-совместимой операционной системой программ.COM для CP / M-80 и MSX. -DOS машины должны запускать код 8080 с C3h, 03h, 01h, который декодируется как инструкция «RET» процессорами x86, тем самым плавно завершая программу, в то время как он будет декодирован как «JP 103h "на процессорах 8080 и просто переходите к следующей инструкции в программе.
Некоторые файлы CP / M-80 3.0.COM могут иметь один или несколько оверлеев RSX, прикрепленных к ним GENCOM. В таком случае они начинаются с дополнительного 256-байтового заголовка (одна страница ). Чтобы указать это, первый байт в заголовке устанавливается в C9h, который работает как подпись, идентифицирующая этот тип COM-файла для исполняемого загрузчика CP / M 3.0, а также инструкция «RET» для 8080-совместимых процессоров, которая приводит к плавному выходу, если файл выполняется в более старых версиях CP / M-80.
C9h никогда не подходит в качестве первого байта программы для любого процессора x86 (он имеет разные значения для разных поколений, но никогда не является значимым первым байтом); исполняемый загрузчик в некоторых версиях DOS отклоняет файлы COM, которые начинаются с C9h, избегая некорректной работы.
CP / M-86 и DOS не имеют общего расширения файла для исполняемых файлов. Таким образом, обычно невозможно перепутать исполняемые файлы. Однако ранние версии DOS имели так много общего с CP / M с точки зрения архитектуры, что некоторые ранние программы DOS были разработаны для совместного использования двоичных файлов, содержащих исполняемый код. Известно, что для этого использовалась программа WordStar 3.2x, которая использовала идентичные файлы оверлея в своих портах для CP / M-86 и MS-DOS и использовала динамически исправленный код для адаптации к различным соглашениям о вызовах этих операционных систем в среде выполнения.
GSX от Digital Research для CP / M-86 и DOS также имеет идентичный двоичный код 16-разрядные драйверы.
DOS драйверы устройств начинаются с заголовка файла, первые четыре байта которого по соглашению равны FFFFFFFFh, хотя это не обязательно. Это фиксируется динамически операционной системой, когда драйвер загружает (обычно в DOS BIOS, когда он выполняет операторы DEVICE в CONFIG.SYS ). Поскольку DOS не отвергает файлы с расширением.COM для загрузки на УСТРОЙСТВО и не проверяет FFFFFFFFh, можно объединить программу COM и драйвер устройства в один файл, поместив инструкцию перехода в точку входа встроенная программа COM в первые четыре байта файла (обычно достаточно трех байтов). Если встроенная программа и разделы драйвера устройства имеют общую часть кода или данных, необходимо, чтобы код имел дело с загрузкой со смещением + 0100h как программа в стиле.COM и с + 0000h как драйвер устройства. Для общего кода, загруженного с "неправильным" смещением, но не предназначенного для позиционно-независимой, это требует исправления внутреннего адреса, аналогичного тому, что в противном случае уже было бы выполнено перемещающим загрузчиком, за исключением того, что в этом случае это должна делать сама загруженная программа; это похоже на ситуацию с самоперемещающимися драйверами, но с программой, уже загруженной в целевое расположение загрузчиком операционной системы.
В DOS некоторые файлы по соглашению имеют расширения файлов, которые не отражают их фактический тип файла. Например, это не драйвер устройства DOS, а двоичный файл базы данных NLS для использования с директивой CONFIG.SYS COUNTRY и драйвером NLSFUNC. Системные файлы PC DOS и DR-DOS IBMBIO.COM и IBMDOS.COM представляют собой специальные двоичные образы, а не программы в стиле COM. Попытка загрузить COUNTRY.SYS с помощью оператора DEVICE или выполнение IBMBIO.COM или IBMDOS.COM в командной строке приведет к непредсказуемым результатам.
Иногда этого можно избежать, используя методы, аналогичные описанным выше. Например, DR-DOS 7.02 и выше включает функцию безопасности, разработанную Маттиасом Р. Полом: если эти файлы вызываются неправильно, крошечные встроенные заглушки просто отображают некоторую информацию о версии файла и корректно завершают работу.
Похожей функцией защиты была инструкция 8080 C7h ("RST 0") в самом начале файлов оверлея языка Z-System, что приводило к горячему запуску (вместо сбой) в CP / M-80 при неправильной загрузке.
Аналогичным образом многие (двоичные) форматы файлов по соглашению включают в себя байт 1Ah (ASCII ^Z ) рядом с началом файла. Этот управляющий символ будет интерпретироваться как «программный» маркер конца файла (EOF), когда файл открывается в небинарном режиме, и, таким образом, во многих операционных системах ( включая RT-11, VMS, CP / M, DOS и Windows), он предотвращает отображение «двоичного мусора» при случайном вводе файла на консоли.
логотип FatELF FatELF - это толстая двоичная реализация для Linux и других Unix-подобных операционных систем. Технически двоичный файл FatELF представляет собой конкатенацию двоичных файлов ELF с некоторыми метаданными, указывающими, какой двоичный файл использовать на какой архитектуре. Помимо абстракции архитектуры ЦП (порядок байтов, размер слова, набор команд ЦП и т. Д.), Есть преимущество двоичных файлов с поддержкой нескольких ядер. ABI и версии.
FatELF имеет несколько вариантов использования, по словам разработчиков:
Доступен пробный образ Ubuntu 9.04. По состоянию на 25 апреля 2020 года FatELF не был интегрирован в основное ядро Linux.
Хотя формат Portable Executable, используемый Windows не позволяет назначать код платформам, но все же можно создать программу-загрузчик, которая отправляет сообщения на основе архитектуры. Это связано с тем, что настольные версии Windows на ARM поддерживают 32-битную эмуляцию x86, что делает ее полезной «универсальной» целью машинного кода. Fatpack - это загрузчик, демонстрирующий концепцию: он включает 32-разрядную программу x86, которая пытается запускать исполняемые файлы, упакованные в разделы ресурсов, один за другим.
Следующие подходы: аналогично толстым двоичным файлам в том, что несколько версий машинного кода одного и того же назначения представлены в одном файле.
GCC и LLVM не имеют толстого двоичного формата, но у них есть файлы толстых объектов для оптимизации времени компоновки (LTO). Поскольку LTO включает задержку компиляции до времени компоновки, объектные файлы должны хранить промежуточное представление, но, с другой стороны, может потребоваться также сохранение машинного кода (для скорости или совместимости). Объект LTO, содержащий как IR, так и машинный код, известен как толстый объект.
Даже в программе или библиотеке, предназначенной для того же архитектура набора команд, программист может пожелать использовать некоторые новые расширения набора команд, сохраняя при этом совместимость со старым ЦП. Это может быть достигнуто с помощью функции многоверсионности (FMV): версии одной и той же функции записываются в программу, и фрагмент кода решает, какую из них использовать, определяя возможности процессора (например, через CPUID ). Компилятор Intel C ++, Коллекция компиляторов GNU и LLVM - все они могут автоматически генерировать многоверсионные функции. Это форма динамической отправки без каких-либо семантических эффектов.
Многие математические библиотеки содержат написанные от руки процедуры сборки, которые автоматически выбираются в зависимости от возможностей процессора. Примеры включают glibc, Intel MKL и OpenBLAS. Кроме того, загрузчик библиотеки в glibc поддерживает загрузку из альтернативных путей для определенных функций ЦП.
