Написание ОС: формат исполняемых файлов
Если я разработал формат исполняемого файла, как создавать в нем файлы? То есть что нужно делать - перенастраивать как-то компилятор-линковщик, писать собственный, хитро писать ld-скрипты или что-нибудь еще? Подскажите, кто сталкивался.
1. Сразу застрелиться
2. Переродиться, посмотреть на свой формат и перейти к пункту №1
3. Переродившись в очередной раз, получить просветление, заюзать существующий формат и снова перейти к пункту №1
1. Сразу застрелиться
2. Переродиться, посмотреть на свой формат и перейти к пункту №1
3. Переродившись в очередной раз, получить просветление, заюзать существующий формат и снова перейти к пункту №1
Ладно, понял...:/)))
Использую формат Linux или UNIX, заодно и совместимость будет...
Кстати, где найти доходчивую информацию об этих форматах? То есть такую, чтобы ее хватило для написания полноценного ранера?
Правда, совместимость с этим "эльфом" все-равно придется потом добавить, а то не поймут.
А пишу я на Си и пользуюсь только встроенным ассемблером, так что компоновщик надо будет делать ой каким мощавым! :=]
А про инлайн-ассемблер - это я просто к слову.
"Файлы приложений и динамических библиотек", что в ELF, что в COFF также имеют одинаковый формат.
Это тоже "к слову".
PS: И да, не забывайте, что у вас есть динамическая линковка, раз уж появились динамические библиотеки, с такими радостями как symbol resoving, fixups, да даже с PIC'ом. Ваш формат все это учитывает?
Это не аргумент. Можно использовать существующие форматы. Лично я использую собственный формат из-за простоты загрузки. Кстати динамические библиотеки могут отличаться по формату от файлов приложений (или иметь расширенный формат) - это не так важно. Например, я до сих пор большинство приложений собираю в формате, в котором отсутствуют средства релокации, а либы грузятся по требованию. Пока приложения не очень сложные, это нормально.
Кстати о компоновщике. Киньте, пожалуйста, ссылку на что-нибудь стоящее по их написанию. Гуглить пробовал. Или за деньги, или ничего полезного. Вообще-то я могу его сделать и так, методом проб и ошибок, но хотелось бы сделать все как надо, то есть по книге.
Линковщик я напишу.
Линковщик я напишу.
Не знаю как остальным, а мне уже страшно... =T_T=
Я тебе на своем опыте могу сказать, что сегментация дает больше минусов, чем плюсов. Я раньше для дров использовал сегменты, потому что еще не было формата, поддерживающего релокацию, и как мне тогда казалось она была и не нужна. Так вот я сильно заблуждался. С переходом к чистой FLAT-модели все стало значительно проще. С прикладными библиотеками все еще сложнее - ты разрушаешь единое адресное пространство приложения (про "библиотеки-процессы" вообще не понял - тут видимо взаимодействовать с библиотеками нужно посредством IPC, что не слишком эффективно). Но дело конечно твое, использовать сегментацию или релокацию.
Попытаюсь объяснить насчет библиотек-процессов. В одном из предыдущих сообщений я сказал, что как приложения так и дллы будут иметь одинаковый способ загрузки и запуска, то есть библиотекой будет процесс. А сейчас объясню по поводу подключения стеков. Таков алгоритм взаимодействия системы и процессов:
1) Приложение совершает системный вызов - эмулированое прерывание
2) Система находит нужный процесс, точку входа(сильно упрощенное описание).
3) В процессе-библиотека система создает новый поток, в котором сегменты кода и данных, соответственно, регистр IP для данного сегмента от библиотеки, а сегмент стека и регистры BP и SP - от приложения. Поток приложения ставится на паузу, а созданный поток - запускается.
4) Созданный поток выполняет все нужные действия и совершает системный вызов, уже другой, дабы отдать результат приложению.
5) Система удаляет поток библиотеки, корректирует стековые регистры потока приложения и запускает его.
Вот так :))
2 Ramon
Я тоже ОЧЕНЬ веселый человек :=))
Речь о том, как эти структуры хранятся в исполняемых файлах и как они должны храниться в объектниках. Если ты "смешаешь" их с обычными данными, то это может стать причиной опережающего чтения данных во время разрешения импортных/экспортных связей, а также появления лишних релоков.
Я думал, одинаковый способ загрузки в одно и тоже адресное пространство. Кто-нибудь думал иначе?
1) Приложение совершает системный вызов - эмулированое прерывание
2) Система находит нужный процесс, точку входа(сильно упрощенное описание).
3) В процессе-библиотека система создает новый поток, в котором сегменты кода и данных, соответственно, регистр IP для данного сегмента от библиотеки, а сегмент стека и регистры BP и SP - от приложения. Поток приложения ставится на паузу, а созданный поток - запускается.
4) Созданный поток выполняет все нужные действия и совершает системный вызов, уже другой, дабы отдать результат приложению.
5) Система удаляет поток библиотеки, корректирует стековые регистры потока приложения и запускает его.
Вот так :))
Нехило ты с либами решил общаться. Я же говорил, IPC. Тут тебе либы (в обычном понимании этого слова) вообще без надобности. Типа "везде процессы".
Ну как вам сказать... Мне кажется, лучший способ пресечь опережающее чтение - не маркировать процесс как работающий, пока загрузка файла не закончится полностью.
Да, кстати, данные, которые нужно уберечь от записи, лучше передавать не через дальние указатели, а методом ООП, то есть вызвал функцию, получил 1 пиксель(на примере изображения), сохранил, запросил еще пиксель, и так далее. Редактировать что-либо без ведома библиотеки невозможно. Наверное... :)
Вот именно. Всё - процессы. Мне кажется именно это имел в виду Таненбаум.
А если серьезно, то не вижу в этом ничего плохого, кроме низкой производительности. Выход - добавить кэш.
Я код и данные загружаю из файла по запросу, а импорт/экспорт разрешаю сразу.
Во истину это уже не библиотеки. На лицо как минимум месиво в терминологии.
PS: Клиент-сервер это отдельный разговор. А все творения тАНЕНБАУМА настоятельно рекомендую сжечь, а прах спустить в фаянсового друга.
А если серьезно, то не вижу в этом ничего плохого, кроме низкой производительности. Выход - добавить кэш.
Это не плохо, но это не либы. Пусть это будет, но только не как безальтернативный традиционному вариант.
Последнее мое сообщение - к предпоследнему вашему
Ну ясен яндекс, что поддержку традиционных либов надо будет потом добавить.
И чем он вам так неугодил?..
Это боян, ибо ничего нового не может быть уже лет эдак 50. Похожий, но более чистый клиент-сервер вы найдете в QNX'се.
PS: А господин тАНЕНБАУМ пишет всякую ерунду да и код у него соответствующий, но почему то считается аффтаритетным экспиртом.
Ну а насчет Таненбаума - дело вкуса.
В смысле - найдете? Исходник они, по-моему, еще не открыли...
Открывали и закрыли снова. Но описалова никто никогда не отменял.
Погодите, если они его уже открывали, то код уже распространился по Сети. Как тогда они его могли закрыть? Ведь каждый может скачать этот код у кого-то, кто успел его скачать раньше.
Успели, скачали снапшот на опред момент. А потом репозиторий был закрыт и все. Если постараетесь то возможно и найдете. Вот только проблема в том, что как бы лицензионное соглашение существует.