OberonCore

Идея с добавлением кода для выхода, похоже, была не очень правильной, вернулся на шаг назад, оставив оригинальный код выхода. В Kernel буду делать процедуру выхода, по крайней мере сейчас думаю именно так.

Кроме того, надо как-то по-другому организовать вызов стартового кода: почему-то при вызове того же самого кода из исполнимого файла (по сравнению с so), все смещения перемещаемых (relocate) элементов оказываются меньше на 4 байта, что естественно ломает вызовы на втором же call (первый идет со смещением 0).

Короче надо думать еще.

В общем, судя по http://www.iecc.com/linker/linker08.html, придется переделывать схему сборки для исполнимых файлов и менять relational-схему на got-схему.

После всех изысканий думаю переписать линкер с нуля.

Нужна большая модульность (в свете потенциального развития ARM и 64-битность) и большая независимость частей для других форматов (Mac OS X x86).

Поэтапно, на базе имеющегося кода, сделать это невозможно?

Оно конечно будет делаться на основе существующего кода.
Просто модульность там прямо просится, исходя из структуры ELF, а существующий код очень трудно модифицировать.
Там надо изменить PIC (position independend code) на абсолютный код, что в текущей реализации нетривиально.

В общем, потихонечку пилю модульный линковщик.

Самая большая неприятность в имеющейся реализации - бесконечные magic numbers, цифры, взятые совершенно без пояснений.
Поэтому я по максимуму стараюсь избегать hardcoded значений.

https://github.com/dmitrys99/BBElfLinker

Файл ElfLinker2.odc

Может быть стоит для начала написать техническую спецификацию, а затем по спецификации уже разрабатывать?

Спецификацию чего?
Спецификация ELF есть в открытом виде.
По ней, собственно, и делаю.

Или спецификацию модуля?
Там тоже все просто - повторяю то, что есть в DevElfLinker - LinkExe, LinkDll, LinkDynExe, LinkDynDll.

Все

То что спецификация формата ELF есть - это понятно.
Но этот формат можно по-разному реализовать. Линкер должен хранить в себе разлинчые списки функций, смещений и так далее. Я немного смотрел формат ELF, насколько я себе представляю, там есть определенные сложности с загрузкой функций из внешних *.so файлов.
У вас линкер будет поддерживать возможность использования функций из внешних *.so файлов?

Попробую дать развернутый ответ.

Как работает ElfLinker сейчас?
Компилятор готовит перемещаемый код с базовым адресом 0, кроме того, для всего кода строится таблица перемещений (на полный BB что-то около 900 записей). Это таблица вызовов процедур и обращения к глобальным переменным, если я правильно понял. Перемещаемый код обертывается в ELF, заголовок строится таким образом, чтобы его можно было загрузить в виде SO.

Для того, чтобы из SO сделать полноценный исполнимый файл, помимо относительно несложных манипуляций с флагами в заголовке необходимо изменить базовый адрес файла. По умолчанию в Линукс этот адрес равен 08048000H. Это - точка входа в приложение. Соответственно, надо чтобы перемещаемые адреса были перемещены при загрузке, простите за тавтологию.

Для этого можно сделать две вещи:
1) Внести в файл (и в заголовок, естественно) секцию .interp, наличие которой, грубо говоря, позволит системе загрузить exe как so, проведя перемещения.
2) Используя абсолютную адресацию изменить адреса процедур, фактически это то, что делает загрузчик.

И то, и другое требует модификации линковщика (ElfLinker).

К сожалению код линковщика, на мой взгляд, безобразный. Магические числа, "зашитые" смещения и пр. Код поплыл при первых же попытках модификации.

Поэтому я начал переписывать.

Теперь о реализации.

Я думаю сделать так:
Код модулей собрать в порядке импорта (как это делает сейчас ElfLinker), это будет одна программная секция. В секции .ini сделать обработку командной строки для последующей передачи в kernel, в секции .fini сделать завершение через int 80h.

Ну а остальное как будет получаться.
Нужны таблицы строк (для описания секций, как минимум), скорее всего понадобится таблица символов, возможно понадобится таблица перемещений и т.д. Буду экспериментировать. Можно, теоретически, добавить символьную информацию для GDB, но это потом, может быть, если понадобится.

Дополнение:
Текущий линковщик умеет подключать *.so файлы. Делается это путем включения соответствующей секции в elf. Туда включаются пути к библиотекам, используемым интерфейсными модулями. Я тоже планирую это сделать.

Димыч, я тут подумал: а почему никто из разработчиков DevElfLinker не пробует использовать библиотеку libelf, включая тебя?

Хорошая идея, надо подумать...

Тут такая проблема: допустим, есть у нас компоновщик, делающий исполнямые файлы. Далее, мы собираем программу и нам потребуется вызвать процедуру из libc. Но для этого требуестя libc проинициализировать, а как?

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

Боюсь, Вы недооцениваете возникающие трудности.
В общем компоновщик-то у меня есть, надо только подкрасить немного.

Я не очень понимаю, чего я не понимаю
Если в исполняемом файле есть упоминание libc, т.е. есть соответствующая секция, тогда загрузчик ее загрузит в процесс и отдаст адрес. В процессе загрузки библиотека инициализируется, т.е. запускается код _init(), если я правильно помню. В конце, если приложение не было срублено, а честно завершилось, вызовется _fini(). Некая аналогия с DLL в винде.

В коде есть упоминание функции из libc, которое суть есть REL или IREL секция, могу ошибиться с названием. Вот когда загрузчик пристыкует библиотеку к процессу, он эти секции и поменяет. Вызов функции, таким образом, это call в секцию, а там уже адрес с правильным смещением.

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

Это в эльфийских ОС так. Во FreeBSB программа сама должна вызвать init, а в линуксе она вызывает init и передает ей main одним из аргументов, а уже эта init вызывает main. Весь этот находится в разных crtN.o, которые присоединяются при линковке.

Может опубликуете?
Различия в заглушках вполне реализуемы.

Я посмотрел, там нормального интерфейса не хватает.
Вот примерно так вызывается.

Вот тут я засомневался. У вас свой, свеженький компоновщик, или тот, что Ominc выкладывали?
Если свой, то мы с вами немного по-разному восприняли слово "опубликовать"