OberonCore

Доброй ночи, коллеги!

Я немного подправил модуль DevElfLinker, он теперь правильно собирает исполнимые файлы. Правильно в том смысле, что readelf не ругается и остальные утилиты тоже.

Засада в том, что у меня под руками только 64-битные инсталляции Linux.
Если у кого есть 32-битные, попробуйте собрать пустой модуль.
Будет при вызове скомпонованного файла выдавать permission denied?

Так, ночь была темной и глубокой.

На полученный результат надо поставить право запуска


Правда при запуске пока падает по segfault.

Сама идея отличная! Ждем новостей.
Попробовал безрезультатно собрать в сборке Freenix:
Kernel$+ Files HostGnome HostFiles StdLoader

Так, разобрался с seg.fault.
Завершение запущенного процесса вызывается в Linux по хитрому:

Этот кусок не генерировался, вместо этого делался ret в ядро, за что приложение ожидаемо получало по рукам.

https://github.com/dmitrys99/BBElfLinker, мало ли.

Долгожданно! Спасибо. Запускается на 32-битке!

Димыч, ElfLinker.odc не компилируется в сборке CPC Edition (Гельмута Цинна) — вываливается с ошибкой в строке:
Это связано с тем, что параметр S процедуры ParseExt помечен модификатором IN. Лечение простое: меняем его на VAR.

Напомню суть проблемы. Она заключается в том, что параметр IN S может быть скрыто изменён внутри S.SetPos, где он помечен как VAR. ББ нестрого разрешает такой трюк, за что нужно бить по рукам.

Так что я бы всем авторам сборок посоветовал воспользоваться фиксом, который ловит данную проблему (которая обсуждалась ещё в рассылке OMinc, и было решено всем миром: фиксу — быть!), и если у кого линкер собрался, значит в вашей сборке фикс не установлен.

В CPC Edition эта ошибка обозначена так:

14. Report passing receiver parameters IN to VAR (Center #38)

P.S. Димыч, благодарю за модификацию линкера. Это давно пора было сделать. В собираемом бинарнике для Linux как-то скрыто решается проблема установки сигналов? Или это нужно делать явно? В исходнике Ofront'а для Linux для этого, например, есть специальный код:

В сборке центра этот фикс с параметром IN применен уже.

Также рекомендую Димычу поглядеть LinLinker от Oberon microsystems.
http://redmine.molpit.com/projects/blac ... Linker.odc

Так, коллеги
Не всё сразу.

План такой:

1. Получить бинарный файл для одного модуля (без Kernel) (выполнено)
2. Убедиться, что argc/argv передаются ядром правильно (выполнено)
3. Собрать систему с Kernel
4. Получить argc/argv для дальнейшего использования
5. Сделать постановку сигналов

Любые замечания и помощь приветствуются.
Еще не могу найти, какой сейчас используется формат файлов по умолчанию во FreeBSD, ELF или a.out.
Если кто знает, подскажите пожалуйста.

После некоторых манипуляций с добавлением флагов, собранный ELF успешно заработал на FreeBSD без необходимости инсталлировать Linux ABI.

Посмотрел. Дешево и сердито. В принципе, имеющийся DevElfLinker делает почти то же самое, только делает это в рамках одного ELF файла и без необходимости привлечения C-загрузчика.

Делюсь некоторыми наблюдениями.

• В сети есть два разных модуля DevElfLinker. Различаются тем, что в них немного по-разному работают процедуры SearchObj. Причина различий пока непонятна.
• Выбор процедур NewRec и NewArr почему-то жестко вшит в линковку ядра, проверяется fingerprint этих процедур. И эти самые fingerprint собственно разные.
• Модуль Files (и HostFiles), видимо, совсем не понимает, что такое символические ссылки - при попытке собрать HostGnome, который находится по символической ссылке, ликновщик останавливается по ошибке "файл не найден".

Чтобы избавиться от символьных ссылок там есть инструмент export. Но может быть дело не в этом, просто HostGnome мог быть не скомпилирован. В целом это не самый необходимый модуль. Он нужен только, чтобы ошибки из ядра при запуске показывать.

Попробовал вот сейчас собрать ядро твоим линковщиком и тоже увидел такую проблему.

Если эту ошибку игнорировать (закоментировать error := TRUE), то собирается файл 91кб, но потом не запускается:

А её не надо игнорировать
Ошибка выдается потому, что в линкованый файл процедура NewRec не попадает.

Закоммитил код, исключающий проверку процедур NewRec и NewArr

Такая же ошибка пока

Дай полный код вызова линковщика

Можно об этом подробнее?

Как вообще сборщик мусора будет работать без NewRec и NewArr?

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

Это был ответ Ивану.
Конечно же, эти процедуры должны попасть в файл, без них никак.
Просто там стоит какая-то странная проверка, использующая конкретные адреса, не совпадающие с фактическими. Поэтому выдается ошибка и сборка останавливается.
Я сделал на это фикс, но надо проверять, похоже где-то еще ошибки.