Comments 22
В свое время баловался этим, могу предложить свой цикл статей phantomexos.blogspot.com
Я дошел до многозадачности, реализации системных вызовов, работы в ring3 и простейшей командной оболочки. Но из-за хреновой реализации управления памятью проект зашел в тупик
Я дошел до многозадачности, реализации системных вызовов, работы в ring3 и простейшей командной оболочки. Но из-за хреновой реализации управления памятью проект зашел в тупик
+1
И да, я бы не рекомендовал крайне Джеймса Маллоя — его код содержит намеренные ошибки, а реализация многозадачности вообще сделана через одно место. В свое время намучился с этим туториалом. Лучше постить свои потуги на osdev.ru, там много толковых ребят, которые способны подсказать полезное.
Вот например так я пришел к реализации многозадачности
Вот например так я пришел к реализации многозадачности
+1
Большое спасибо за интересную статью! Было бы ещё очень здорово в таком же духе, но про x86_64.
+2
Вместо того чтобы руками собирать тулчейн можно взять github.com/crosstool-ng/crosstool-ng. Только непонятно, зачем собирать кросс-компилятор под x86 без libc, если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.
+1
если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.
У меня аналогичный вопрос. Всё нормально собирается хостовым компилятором с соответствующими опциями.
И ещё один вопрос — зачем NASM? Если есть as, вызываемый gcc автоматом, когда тот натыкается на ассемблерный исходник? Ну да, придется попотеть освоив AT&T-синтаксис, ну так это, во-первых несложно, а во вторых — синтаксис ассемблерных вставок и так AT&T. Зачем нужен плесневелый nasm, ради только intel-нотации?
Еще замечание, касательно qemu. Обязательно надо упомянуть о том, что нельзя категорически использовать опцию -enable-kvm. С ней отладка не будет работать
0
В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде
По поводу NASM — это просто один из инструментов, применение которого не вызывает особых проблем. Можно было использовать GAS, FASM или TASM. А можно было NASM. Что использовать Вам — дело Ваше.
Про
-nostdinc
, -nostdlib
, -m32
, которые легко забыть.По поводу NASM — это просто один из инструментов, применение которого не вызывает особых проблем. Можно было использовать GAS, FASM или TASM. А можно было NASM. Что использовать Вам — дело Ваше.
Про
-enable-kvm
упомяну.0
В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде -nostdinc, -nostdlib, -m32, которые легко забыть.
Мне кажется, что когда настроить флаги стандартного компилятора проще и рациональнее чем собирать компилятор самому.
0
В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру
Ну вообще-то нет, не может. Максимум — к функциям из libc, типа abort. Плюс в коде раскрутки стека при исключении есть проверка, специфичная для ОС, но исключения — это вообще отдельная тема, голого компилятора который вы построили для них тоже не хватит.
0
Прошу прощения, имел в виду хостовые стандартные функции, а не ядро. Но, тем не менее, для этого нужна хостовая libc, а она может вызывать проблемы.
0
тем не менее, для этого нужна хостовая libc
Вовсе нет, никто не запрещает вам определить abort, memcpy, memmove, memset и memcmp в своём коде, по мере необходимости.
0
Всё решается двумя ключами
-nostdlib — не используем стандартных библиотек
-nostdinc — не используем стандартных заголовков
нет нужды собирать компилятор отдельно под задачу сборки ядра своей ос
Ваш пример пустого ядра я собирал таким makefile
и все работало
-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)
и все работало
+1
С -nostdinc не будет весьма полезных заголовков, которые не требуют libc, таких как stddef.h и stdarg.h. Что легче, переписать stdarg.h или собрать компилятор?
0
Переписать ашник. И вот почему: нельзя просто так взять и пересобрать компилятор. Он ещё должен тесты пройти, почитайте книгу LFS или вот этот материал и станет понятно, что гарантированно работоспособный компилятор и комплект binutils собирается не с наскока, а вдумчиво и долго с обязательным прохождением тестов. На моей машине сборка gcc с тестами заняла 2,5 часа, например + примерно столько же времени на чтение и подготовку
0
Переписать ашник.
Не, вот это точно неправильно. Скопировать стандартный в отдельный сисрут — может быть. Переписать самому — точно нет.
станет понятно, что гарантированно работоспособный компилятор и комплект binutils собирается не с наскока, а вдумчиво и долго с обязательным прохождением тестов
Порекламирую crosstool-NG ещё раз. Бэкпортированные патчи из мэйнлайнов компонентов тулчейна и коллективное тестирование идут в комплекте.
+1
Правильно переписать. Пересобрать компилятор не правильно. Если вы пишите туториал. То ненужно в них советовать неправильные подходы.
0
Этот makefile будет неустойчиво работать с make -j, потому что link не зависит от $(SOURCES) и перечислен наравне с ними в пререквизитах для all. Правильнее было бы так:
all: kernel
kernel: $(SOURCES)
0
Спасибо. Довольно редки здесь статейки на такую тематику. Если Вы вдруг решите делать что-то вроде цикла статей, хотелось бы чего-нибудь и по поводу UEFI. В частности интересна тема написания загрузчиков (не ради самих загрузчиков, а ради того, чтобы знать, как оно робит), да и в целом как ОС используют UEFI.
+1
Плюсую. Это у меня один из проектов, до которых не дошли руки, но сильно чешутся — программирование под голое железо х86_64, начиная с загрузки своего приложения без использования стороннего кода.
0
Там почти не о чем писать, к сожалению, потому что любое EFI-приложение может выступать в качестве загрузчика, а написание простейшего EFI-приложения на Хабре уже не раз освещалось, и в тех примерах достаточно заменить в inf-файле DXE_DRIVER на UEFI_APPLICATION, и у вас получится нужный вам загрузчик.
0
Спасибо за статью! Крайне приятно видеть на хабре не статью о том, как надо верстать анимацию в андроид приложение на джаваскрипте, а о чём-то действительно серьезном, фундаментальном, так сказать.
0
vodozhaba как Вы относитесь к миссии проекта Embox?
0
Sign up to leave a comment.
Как выйти на путь разработки ОС