Зачем нужна линковка программы, собранной nasm

Есть вот такая программа(синтаксис NASM)
Я выполнил команду и попытался выполнить файл helloasm, но получил ошибку при запуске...
Позже, я узнал, что этот файл не предназначен для запуска, и для того чтобы запустить, нужно выполнить две команды:
Вторая команда, насколько я понял, линкер, а зачем он тут нужен? Что с чем он линкует? Неужели системные вызовы не могут работать так без линковки? Просто я в коде не вижу вызовов функций из каких-нибудь системных библиотек

0

Ну так извольте поделится

0

blbulyan, у писателя лучше получится.
Я же ответил, одна из причин много-модульность,
вторая - при сборки : сборщик делает работу дополнительную :
экспортирует, устанавливает, размещает...

0

0

Сообщение от blbulyan Что с чем он линкует?

Не что с чем, а просто линкует. Объектный файл превращает в исполяемый.

Ассемблер превращает текстовый исходник программы в объектный файл, компоновщик из одного или нескольких объектных делает исполняемый. Что тут не понятно ?
И в общем так поступают все ассемблеры для IBM PC кроме FASM-а. Этот стоит особняком.

Добавлено через 10 минут
Собственно у программистского термина link на русский встречаются три перевода :
- ужасной калькой с английского линковать (и кажется, что что-то с чем-то ?)
- связывать (и тоже кажется, что что-то с чем-то ?)
- компоновать (вот тут уже вопросов не возникает, компоновать можно и единственный объект)
Ну и вот когда деревья были большими linker называли компоновщиком и странных вопросов не задавали.

1

Ну то что линкер - компоновщик, это я в курсе. Вопрос состоит в том, неужели объектный файл который выдаёт nasm не готов к исполнению? Или помимо ассемблерного кода исполняемый файл должен содержать ещё что-то? По идее, я даже точку входа указал в ассемблерном коде, что тогда дополнительного добавляет компоновщик?

0

Объектный файл не готов к исполнению.

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

В общем случае исполняемые файлы и объектные файлы имеют разный формат, потому-что у них разное назначение. Исполняемый файл может быть и голым кодом безо всякого формата, таковы файлы .COM для MS-DOS. А объектный файл содержит :
- таблицу глобальных, экспортируемых символов (в данном термином словом символ обозначается идентификатор, например blablabla), с которыми могут связываться другие объектные файлы при компоновке
- таблицу внешних еще не разрешенных символов, которые должны быть при компоновке связаны с глобальными, экспортируемыми символами из других объектных файлов
- таблицу перемещения, поскольку все адреса в коде объектного файла не окончательны, а относительны его начала

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

Полученный исполняемый файл может иметь окончательные адреса и дальнейшего перемещения может уже не требовать. Таковыми можно сделать 32-разрядные EXE для Windows скомпоновав их в предположении, что они лягут в виртуальном адресном пространстве с фиксированного адреса 400000h. Таковы COM-файлы для MS-DOS, компонуемые исходя из того, что они лягут с фиксированного смещения 100h в адресном пространстве сегмента 64К. В общем при компоновке таких исполняемых файлов производится перемещение кода прибавлением констант 400000h и 100h к тем местам в коде, которые указаны таблицей перемещения объектного файла.

Но полученный исполняемый файл может быть и таким, что сам будет требовать перемещения при загрузке и сам иметь таблицу перемещения. Только это может быть совсем другое перемещение, чем в объектном файле. Например в 16-разрядном мире MS-DOS адреса представляются парой сегмент:смещение и в объектных файлах при компоновке перемещаются смещения, поскольку гранула перемещения один байт. А при загрузке в память EXE гранула перемещения параграф, поэтому при запуске в EXE перемещаются сегменты. Т.е. в случае MS-DOS у объектных и исполняемых файлов есть таблицы перемещения, но это совсем разные перемещения.

Но в линейном адресном пространстве 32 бита перемещение может быть только единственным образом, поэтому у него будет неизбежно одинаковый механизм и для объектных и для исполняемых файлов. Поэтому для такого пространства возможен единый для объектных и исполняемых файлов формат ELF. Хотя все равно объектные и исполняемые файлы отличаются соответствующим флагом в заголовке ELF, потому-что объектные ELF исходя из общего случая считаются не скомпонованным, не до конца связанным кодом, пусть даже в твоем конкретном случае связывать фактически и нечего.

Добавлено через 12 минут
Ну и наконец если в операционке используются разделяемые библиотеки .DLL или .so , то в исполняемом файле будет таблица неразрешенных символов с именами функций этих библиотек. Тогда при загрузке исполняемого файла на исполнение будет производится еще одно связывание, второе связывание. Первое при компоновке объектных файлов в исполняемый, а второе при загрузке исполняемого файла в память на исполнение.
В общем создается некоторая технология и пропустить этапы этой технологии, типа сразу запустить объектный файл на исполнение опустив компоновку не получится. Технология рассчитана на общий случай и исключения для частного случая "в объектном файле связывать нечего" не делаются.

4

Ethereal, А в исполняемом файле формата elf тоже есть таблица смещения?

0

Перемещения.
ELF-файл состоит из нескольких секций и заголовок описывает эти секции.
Таблица перемещения в 32-разрядном ELF-файле располагается в секции с именем .rel.txt
А теперь смотрю на файлы Фряхи (Free-BSD)
Объектные файлы обычно имеют расширение .o , смотрю в них обычым текстовым редактором и поиск строчки .rel.txt ее находит.
Архивы объектных файлов обычно имеют расширение .a , смотрю в них обычым текстовым редактором и поиск строчки .rel.txt ее находит.
А вот в исполняемых файлах без расширения этой строчки нет. Зато вместо нее есть .rel.plt
А вот в разделяемых библиотеках с расширением .so тоже нет. Зато есть .rel.plt и .rel.dyn

Короче
.rel.txt - это таблица перемещения для статической компоновки компонощиком link
Про .rel.plt и .rel.dyn я никогда не интересовался, но насколько понимаю это таблица для второго связывания о котором я писал выше (plt = Procedure Linkage Table) и таблица перемещения разделяемой библиотеки, поскольку такие библиотеки динамически (dyn) грузятся в память в заранее не известном порядке и по заранее неизвестным адресам. И при загрузке их код каждый раз приходится настраивать по месту с помощью таблицы перемещения.

Т.е. таблицы перемещения, которая есть в объектом файле в исполняемом файле нет. Есть таблица для связывания с разделяемыми библиотеками.

Добавлено через 9 минут
З.Ы.
Ну и почему в именах секций rel . А потому, что по английски перемещение - relocation.

З.З.Ы.
Файл с кодом и таблицей перемещения к этому коду обзывается relocatable - перемещаемый. Ну и сам код тоже обзывается перемещаемым.
Код, написанный так, что может перемещаться, но таблицы перемещения не требует называется PIC-код, position independent code, позиционно-независимый код. Чтобы писать такой код для x86-го процика надо использовать особые трюки.
Ну и код, который не может быть перемещен потому, что таблицы перемещения к нему нет или написан так, что перемещение невозможно называется неперемещаемым или загружаемым по фиксированному адресу.
Вот все варианты и терминология.

2