Ответ 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 файлы) с объектным кодом? Символы, как в отладочных символах, и их использование при повторном размещении объектных файлов на другой машине.
Я думаю, что это не связано с используемым форматом исполняемого файла. Если вы хотите отлаживать, вы должны генерировать отладочную информацию независимо от того, что. Но если вам не нужно отлаживать, то вы можете их опустить, конечно.