Как стать автором
Обновить

Комментарии 22

В свое время баловался этим, могу предложить свой цикл статей phantomexos.blogspot.com

Я дошел до многозадачности, реализации системных вызовов, работы в ring3 и простейшей командной оболочки. Но из-за хреновой реализации управления памятью проект зашел в тупик
И да, я бы не рекомендовал крайне Джеймса Маллоя — его код содержит намеренные ошибки, а реализация многозадачности вообще сделана через одно место. В свое время намучился с этим туториалом. Лучше постить свои потуги на osdev.ru, там много толковых ребят, которые способны подсказать полезное.

Вот например так я пришел к реализации многозадачности
Ой. Как раз хотел сделать об этом оговорку, но по пути на Хабр на месте фразы «не лишён изъянов» потерялась ссылка на список подобных ошибок. Исправил. Спасибо!

Большое спасибо за интересную статью! Было бы ещё очень здорово в таком же духе, но про x86_64.

Вместо того чтобы руками собирать тулчейн можно взять github.com/crosstool-ng/crosstool-ng. Только непонятно, зачем собирать кросс-компилятор под x86 без libc, если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.
если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.


У меня аналогичный вопрос. Всё нормально собирается хостовым компилятором с соответствующими опциями.

И ещё один вопрос — зачем NASM? Если есть as, вызываемый gcc автоматом, когда тот натыкается на ассемблерный исходник? Ну да, придется попотеть освоив AT&T-синтаксис, ну так это, во-первых несложно, а во вторых — синтаксис ассемблерных вставок и так AT&T. Зачем нужен плесневелый nasm, ради только intel-нотации?

Еще замечание, касательно qemu. Обязательно надо упомянуть о том, что нельзя категорически использовать опцию -enable-kvm. С ней отладка не будет работать
В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде -nostdinc, -nostdlib, -m32, которые легко забыть.

По поводу NASM — это просто один из инструментов, применение которого не вызывает особых проблем. Можно было использовать GAS, FASM или TASM. А можно было NASM. Что использовать Вам — дело Ваше.

Про -enable-kvm упомяну.
В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде -nostdinc, -nostdlib, -m32, которые легко забыть.

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

Ну вообще-то нет, не может. Максимум — к функциям из libc, типа abort. Плюс в коде раскрутки стека при исключении есть проверка, специфичная для ОС, но исключения — это вообще отдельная тема, голого компилятора который вы построили для них тоже не хватит.
Прошу прощения, имел в виду хостовые стандартные функции, а не ядро. Но, тем не менее, для этого нужна хостовая libc, а она может вызывать проблемы.
тем не менее, для этого нужна хостовая libc

Вовсе нет, никто не запрещает вам определить abort, memcpy, memmove, memset и memcmp в своём коде, по мере необходимости.
Всё решается двумя ключами

-nostdlib — не используем стандартных библиотек
-nostdinc — не используем стандартных заголовков

нет нужды собирать компилятор отдельно под задачу сборки ядра своей ос

Ваш пример пустого ядра я собирал таким makefile

#------------------------------------------------------
#
# Правила сборки кода ядра
#
#------------------------------------------------------

# Исходные объектные модули
SOURCES=init.o main.o
# Флаги компилятора языка C
CFLAGS=-nostdlib -nostdinc -fno-builtin -fno-stack-protector -m32 -g
# Флаги компоновщика
LDFLAGS=-T link.ld -m elf_i386
# Флаги ассемблера
ASFLAGS=--32
# Правило сборки
all: $(SOURCES) link
# Правило очистки
clean:
-rm *.o kernel
# Правило компоновки
link:
ld $(LDFLAGS) -o kernel $(SOURCES)


и все работало
С -nostdinc не будет весьма полезных заголовков, которые не требуют libc, таких как stddef.h и stdarg.h. Что легче, переписать stdarg.h или собрать компилятор?
Переписать ашник. И вот почему: нельзя просто так взять и пересобрать компилятор. Он ещё должен тесты пройти, почитайте книгу LFS или вот этот материал и станет понятно, что гарантированно работоспособный компилятор и комплект binutils собирается не с наскока, а вдумчиво и долго с обязательным прохождением тестов. На моей машине сборка gcc с тестами заняла 2,5 часа, например + примерно столько же времени на чтение и подготовку
Переписать ашник.

Не, вот это точно неправильно. Скопировать стандартный в отдельный сисрут — может быть. Переписать самому — точно нет.

станет понятно, что гарантированно работоспособный компилятор и комплект binutils собирается не с наскока, а вдумчиво и долго с обязательным прохождением тестов

Порекламирую crosstool-NG ещё раз. Бэкпортированные патчи из мэйнлайнов компонентов тулчейна и коллективное тестирование идут в комплекте.
Правильно переписать. Пересобрать компилятор не правильно. Если вы пишите туториал. То ненужно в них советовать неправильные подходы.
Этот makefile будет неустойчиво работать с make -j, потому что link не зависит от $(SOURCES) и перечислен наравне с ними в пререквизитах для all. Правильнее было бы так:
all: kernel
kernel: $(SOURCES)
Спасибо. Довольно редки здесь статейки на такую тематику. Если Вы вдруг решите делать что-то вроде цикла статей, хотелось бы чего-нибудь и по поводу UEFI. В частности интересна тема написания загрузчиков (не ради самих загрузчиков, а ради того, чтобы знать, как оно робит), да и в целом как ОС используют UEFI.
Плюсую. Это у меня один из проектов, до которых не дошли руки, но сильно чешутся — программирование под голое железо х86_64, начиная с загрузки своего приложения без использования стороннего кода.

Там почти не о чем писать, к сожалению, потому что любое EFI-приложение может выступать в качестве загрузчика, а написание простейшего EFI-приложения на Хабре уже не раз освещалось, и в тех примерах достаточно заменить в inf-файле DXE_DRIVER на UEFI_APPLICATION, и у вас получится нужный вам загрузчик.

Спасибо за статью! Крайне приятно видеть на хабре не статью о том, как надо верстать анимацию в андроид приложение на джаваскрипте, а о чём-то действительно серьезном, фундаментальном, так сказать.

vodozhaba как Вы относитесь к миссии проекта Embox?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории