Объектный файл

Файл, содержащий машинный код перемещаемого формата.

Объектный файл — это файл, который содержит машинный код или байт-код , а также другие данные и метаданные , сгенерированные компилятором или ассемблером из исходного кода в процессе компиляции или сборки. Генерируемый машинный код известен как объектный код .

Объектный код обычно является перемещаемым и не всегда исполняемым напрямую . Существуют различные форматы объектных файлов, и один и тот же машинный код может быть упакован в разные форматы объектных файлов. Объектный файл также может работать как общая библиотека .

Метаданные, которые могут включать объектные файлы, могут использоваться для связывания или отладки; он включает в себя: информацию для разрешения символических перекрестных ссылок между различными модулями, информацию о перемещении , информацию о развертывании стека , комментарии , программные символы , информацию об отладке или профилировании . Другие метаданные могут включать дату и время компиляции, имя и версию компилятора, а также другую идентифицирующую информацию.

Термин «объектная программа» датируется как минимум 1950-ми годами:

Термин в автоматическом программировании, обозначающий программу на машинном языке, создаваемую машиной путем перевода исходной программы, написанной программистом, на язык, аналогичный алгебраической записи. ^[1]

Компоновщик используется для объединения объектного кода в одну исполняемую программу или библиотеку, при необходимости извлекая предварительно скомпилированные системные библиотеки .

Форматы объектных файлов

Существует множество различных форматов объектных файлов; Первоначально каждый тип компьютера имел свой собственный уникальный формат, но с появлением Unix и других портативных операционных систем некоторые форматы, такие как ELF и COFF , были определены и использовались в разных типах систем.

Некоторые системы проводят различие между форматами, которые являются непосредственно исполняемыми, и форматами, требующими обработки компоновщиком . Например, в OS/360 и последующих версиях первый формат называется загрузочным модулем , а второй — объектным модулем . В этом случае файлы имеют совершенно разные форматы. ^[2] DOS и Windows также имеют разные форматы файлов для исполняемых файлов и объектных файлов, например Portable Executable для исполняемых файлов и COFF для объектных файлов в 32-битной и 64-битной Windows.

Unix и Unix-подобные системы использовали один и тот же формат для исполняемых и объектных файлов, начиная с исходного формата a.out . Некоторые форматы могут содержать машинный код для разных процессоров, правильный из которых выбирается операционной системой при загрузке программы. ^{[3] [4]}

Проектирование и/или выбор формата объектного файла является ключевой частью общего проектирования системы. Это влияет на производительность компоновщика и, следовательно, на работу программистов во время разработки программы. Если формат используется для исполняемых файлов, дизайн также влияет на время, необходимое программам для запуска , и, следовательно, на скорость реагирования для пользователей.

Библиотека дескрипторов двоичных файлов проекта GNU (библиотека BFD) предоставляет общий API для манипулирования объектными файлами в различных форматах.

Абсолютные файлы

Многие ранние компьютеры или небольшие микрокомпьютеры поддерживали только абсолютный формат объекта. Программы не подлежат перемещению; их необходимо ассемблировать или скомпилировать для выполнения по определенным, заранее определенным адресам. Файл не содержит информации о перемещении или связывании. Эти файлы могут быть загружены в память для чтения/записи или сохранены в постоянной памяти . Например, монитор Motorola 6800 MIKBUG содержит процедуру чтения абсолютного объектного файла ( формат SREC ) с бумажной ленты . ^[5] COM-файлы DOS представляют собой более поздний пример абсолютных объектных файлов. ^[6]

Сегментация

Большинство форматов объектных файлов структурированы как отдельные разделы данных, каждый раздел содержит данные определенного типа. Эти разделы известны как «сегменты» из-за термина « сегмент памяти », который ранее был распространенной формой управления памятью . Когда программа загружается в память загрузчиком , загрузчик выделяет для программы различные области памяти. Некоторые из этих областей соответствуют разделам объектного файла и поэтому обычно имеют одни и те же имена. Другие, такие как стек, существуют только во время выполнения. В некоторых случаях перемещение выполняется загрузчиком (или компоновщиком) для указания фактических адресов памяти. Однако для многих программ или архитектур перемещение не является необходимым, поскольку оно обрабатывается модулем управления памятью или позиционно-независимым кодом . В некоторых системах сегменты объектного файла затем можно скопировать (выгрузить по страницам) в память и выполнить без необходимости дальнейшей обработки. В этих системах это можно делать лениво , то есть только тогда, когда на сегменты ссылаются во время выполнения, например, через отображенный в памяти файл , поддерживаемый объектным файлом.

Типы данных, поддерживаемые типичными форматами объектных файлов: ^[7]

• Заголовок (описательная и управляющая информация)
• Сегмент кода («текстовый сегмент», исполняемый код)
• Сегмент данных (инициализированные статические переменные )
• Сегмент данных только для чтения ( rodata , инициализированные статические константы )
• Сегмент BSS (неинициализированные статические данные, как переменные, так и константы)
• Внешние определения и ссылки для связывания
• Информация о переезде
• Информация о динамическом связывании
• Отладочная информация

Сегменты в разных объектных файлах могут комбинироваться компоновщиком в соответствии с правилами, указанными при определении сегментов. Существуют соглашения для сегментов, общих для объектных файлов; например, в DOS существуют разные модели памяти , которые определяют имена специальных сегментов и могут ли они быть объединены. ^[8]

Формат отладочных данных отладочной информации может быть либо неотъемлемой частью формата объектного файла, как в COFF , либо полунезависимым форматом, который может использоваться с несколькими объектными форматами, такими как stabs или DWARF .

Смотрите также

• Формат объектного файла OS/360
• Шестнадцатеричный формат объектного файла Intel (обычно с расширением файла .HEX, но иногда и с .OBJ).
• Формат объектного модуля (ICL) (OMF для ICL VME)
• Формат объектного модуля (Intel) (OMF для Intel 8080/8085, OBJ для Intel 8086)
• Мачо

Рекомендации

1. Врубель, маршал Х. (1959). Букварь программирования для цифровых компьютеров. Нью-Йорк, США: МакГроу-Хилл . п. 222 . Проверено 31 июля 2020 г.
2. Редактор и загрузчик IBM OS Linkage (PDF) . Корпорация IBM . 1973. с. 16 . Проверено 6 августа 2012 г.
3. «Универсальные двоичные файлы и 32-битные/64-битные двоичные файлы PowerPC». Справочник по форматам файлов OS X ABI Mach-O . Apple Inc., 04 февраля 2009 г. [2003 г.]. Архивировано из оригинала 4 сентября 2014 г.
4. «FatELF: Универсальные двоичные файлы для Linux» . Проверено 2 августа 2020 г.
5. Уайлс, Майк; Феликс, Андре. MCM6830L7 MIKBUG/MINIBUG ROM (PDF) . Motorola Semiconductor Products, Inc. Проверено 31 июля 2020 г.
6. Годзе, Дипали А.; Годзе, Атул П. (2008). Микропроцессор (1-е изд.). Пуна, Индия: Технические публикации. стр. 3–15. ISBN 978-81-8431-355-0.
7. Мауэрер, Вольфганг (2010). «Приложение E. Бинарный формат ELF». Профессиональная архитектура ядра Linux . Джон Уайли и сыновья . п. Приложение E. ISBN 978-0-470-34343-2. Проверено 1 августа 2020 г.
8. Ирвин, Кип Р. (1993). Язык ассемблера для IBM-PC (2-е изд.). Нью-Йорк, США: Макмиллан. ISBN 0-02-359651-1.

дальнейшее чтение

• Левин, Джон Р. (2000) [октябрь 1999 г.]. «Глава 3: Объектные файлы». Линкеры и загрузчики . Серия Моргана Кауфмана по разработке программного обеспечения и программированию (1-е изд.). Сан-Франциско, Калифорния, США: Морган Кауфманн . п. 256. ИСБН 1-55860-496-0. OCLC  42413382. Архивировано из оригинала 25 января 2013 г. Проверено 12 января 2020 г.Код: [1][2] Ошибки: [3]
• Формат файла Microsoft OBJ. Microsoft , Служба поддержки продуктов. Примечание по применению SS0288. Архивировано из оригинала 9 сентября 2017 г. Проверено 21 августа 2017 г.
• Эллиотт, Джон К. (2002). «Формат файла Microsoft REL». seasip.info . Архивировано из оригинала 25 ноября 2023 г. Проверено 25 ноября 2023 г.(Примечание. Описание формата файла Microsoft REL для перемещаемых объектов, также используемого Digital Research.)
• Эллиотт, Джон К. (5 июня 2012 г.) [02 января 2000 г.]. «Формат файла PRL». seasip.info . Архивировано из оригинала 26 января 2020 г. Проверено 26 января 2020 г.[4]
• Фрейзер, Кристофер «Крис» В .; Хэнсон, Дэвид Р. (апрель – май 1982 г.) [1981-09-09, 1981-11-02]. «Машинно-независимый компоновщик» (PDF) . Программное обеспечение: практика и опыт  [d] . Университет Аризоны, Тусон, Аризона, США: John Wiley & Sons, Ltd. 12 (4): 351–366. дои : 10.1002/спе.4380120407. ISSN  0038-0644. Архивировано (PDF) из оригинала 28 ноября 2023 г. Проверено 28 ноября 2023 г.(16 страниц)
• Монтюэль, Жан; Уиллерс, Ян (25–28 сентября 1979 г.) [октябрь 1978 г.]. Написано в ЦЕРН, Женева, Швейцария. Кросс-программное обеспечение с использованием формата универсального объектного модуля, CUFOM. Евро ИФИП, Лондон, Великобритания. ЦЕРН-DD/78/20 . Проверено 28 ноября 2023 г.(1+23 страницы)
• Универсальный формат микропроцессора для объектных модулей, MUFOM (проект документа), Рабочая группа IEEE , P695lD2
• Монтюэль, Жан; Виллерс, Ян (сентябрь 1982 г.). "Письмо редактору". Программное обеспечение: практика и опыт  [d] . ЦЕРН, Женева, Швейцария: John Wiley & Sons, Ltd. 12 (9): 883–884 [884]. дои : 10.1002/спе.4380120909 . ISSN  0038-0644. Архивировано из оригинала 28 ноября 2023 г. Проверено 28 ноября 2023 г.(1 страница) (Примечание. Описывает историю и связь IEEE 695 с CUFOM и MUFOM.)
• IEEE 695-1990: Стандарт IEEE для универсального формата микропроцессора для объектных модулей. ИИЭЭ . 05.02.1990. doi : 10.1109/IEESTD.1990.101062. ISBN 978-0-7381-3028-6.(Примечание: Superseeds IEEE 695-1985 (1985-09-09)).