Различия в использовании. a.out,.ELF,.EXE и .COFF

Не поймите меня неправильно, посмотрев заголовок вопроса - я знаю, что это (формат для переносимых исполняемых файлов). Но моя область интереса немного отличается

МОЕ СОКРАЩЕНИЕ

Я участвую в приложениях повторного хостинга/перенацеливания, которые изначально принадлежат третьим сторонам. Проблема в том, что иногда форматы объектных кодов также находятся в форматах .elf,.COFF и все еще говорят: "Исполняемые и связанные".

Я в первую очередь пользователь Windows и знаю, что когда вы компилируете и собираете свой код на C/С++, вы получаете что-то похожее на .o или .obj. которые не исполняются (ну, я никогда не пытался их выполнить). Но когда вы завершите связывание статических и динамических библиотек и завершите создание, появится исполняемый файл. Мое понимание заключается в том, что вы можете продолжить и связать этот исполняемый файл или "bash" проверить его с помощью какой-либо формы script, если это необходимо.

Однако в Linux (или в UNIX-подобных системах) есть файлы .o после компиляции и сборки кода C/С++. И как только связь будет выполнена, исполняемый файл будет в формате a.out(по крайней мере, в дистрибутиве Linux Ubuntu). Это может быть очень хорошо в другом дистрибутиве. В моем быстром веб-поиске ни один из источников ничего не упоминал о файлах .o в качестве исполняемых файлов.

ВОПРОСЫ

Поэтому мой вопрос превращается в следующее:

Каковы истинные определения для переносимых исполняемых файлов и объектного кода?
Как выглядит то, что платформа Windows и UNIX охватывает оба исполняемых файла annd object code в том же формате файла (.COFF,.elf).
Я неверно истолковываю "Linkable"? Моя интерпретация "Linkable" - это компилируемый объектный код, который затем может быть "привязан" к другим статическим/динамическим библиотекам ссылок. Это глупая мысль?
На основании вопроса 1. (и, возможно, 2) мне нужно использовать таблицы символов (например,.LUM или .MAP файлы) с объектным кодом? Символы как в отладочных символах и их использование при повторном размещении файлов исполняемых файлов/объектов на другой машине.

Заранее благодарим за правильные подталкивания. Между тем, я буду продолжать копать и обновлять вопрос, если это необходимо.

UPDATE

Мне удалось выкопать это откуда-то:( Кажется, что я много глотаю.

Ответ 1

Я в первую очередь пользователь Windows и знаю, что при компиляции кода на C/С++ вы получаете что-то похожее на .o или .obj. которые не выполняются

Ну, в прошлый раз, когда я скомпилировал материал в Windows, результатом компиляции был файл .obj, что и есть его название: object file. Вы правы в том, что это не исполняемый файл сам по себе. Он содержит машинный код, который еще не содержит достаточную информацию для непосредственного запуска на CPU.

Однако в Linux (или UNIX-подобных системах) есть файлы .o после компиляции кода C/С++. И как только связь будет выполнена, исполняемый файл будет в формате a.out(по крайней мере, в дистрибутиве Linux Ubuntu). Это может быть очень хорошо. В другом дистрибутиве.

Жизнь в 90-е годы, то есть: P Нет современных компиляторов. Я знаю, что целевой формат a.out является стандартным форматом вывода для объектного кода. Возможно, это вводящий в заблуждение по умолчанию GCC, чтобы помещать объектный код в файл с именем a.out, если не указано явное имя выходного файла, но если вы запустите команду file на a.out, вы обнаружите, что это ELF файл. Формат a.out является древним, и это своего рода "де-факто устаревшее".

Каковы истинные определения для переносимых исполняемых файлов и объектного кода?

У вас уже есть ссылка Википедии на объектные файлы, здесь, на "Portable Executable" .

Как выглядит платформа Windows и UNIX охватывает оба исполняемых файла annd object code в том же формате файла (.COFF,.elf).

Потому что формат ELF (и, очевидно, COFF тоже) был спроектирован так. И почему бы нет? Это всего лишь тот же машинный код, в конце концов, вполне логично использовать один формат файла на всех этапах компиляции. Точно так же, как нам не нравится, когда динамические библиотеки и автономные исполняемые файлы имеют другой формат. (То почему ELF называется ELF - это "Исполняемый и Связываемый формат".)

Я неверно истолковываю "Связь"?

Я не знаю. Из вашего вопроса мне непонятно, что вы думаете о "связном". В общем, это означает, что это файл, который может быть связан с, i. е. библиотека.

На основании вопроса 1. (и, возможно, 2) мне нужно использовать таблицы символов (например,.LUM или .MAP файлы) с объектным кодом? Символы, как в отладочных символах, и их использование при повторном размещении объектных файлов на другой машине.

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