Board.KolibriOS.org

На данный момент список средств отладки Kolibri ограничен следующими элементами:
1) Bochs (или другой эмулятор с поддержкой отладки (?))
2) MeOsDebug уважаемого товарища halyavin'а
3) Доска отладки
При этом пункт 2) требует винды, Bochs более либерален, но под Kolibri не портирован, а доска отладки не может заменить полноценной отладки.
А нужен ли в Kolibri настоящий отладчик?
И если нужен, то какой?
Написание кода я беру на себя, а вот идеи хотелось бы обсудить.
Существуют две существенно различных категории (неэмулирующих) отладчиков:
1. Отладчики user-mode (отладчики 3-кольца). В этом случае отладчик представляет собой приложение, которое вызывает специальные системные функции для контроля исполнения другого процесса.
2. Отладчики kernel-mode (отладчики 0-кольца). В этом случае отладчик исполняется в 0-кольце и имеет возможность контролировать всю систему.
В первом случае достаточно добавить в ядро некоторые функции по запуску под отладкой и контролю отладки, написать заурядное приложение 3-кольца - отладчик и предоставить пользователю возможность запускать его, когда надо.
Во втором случае возможностей больше (например, можно отлаживать ядро), но и цена за это тоже выше (например, повисание/падение отладчика 0-кольца скорее всего приведет к необходимости давить Reset). В этом случае возникает куча вопросов в связи с полным отсутствием какой-либо драйверной модели. Внедрять ли отладчик в ядро или держать отдельным файлом? Когда его загружать? Как его загружать? Куда его загружать? Стоит ли его загружать?
В общем, высказывайте ваши мнения.

diamond
На примере Windows мы видим, что встроенная система отладки ядра просо бессмысленна.
Юзерам она нужна как затычка в жопе (хотя как раз у них и возникает больше всего проблем), а программисты составляют всего 1% (в лучшем случае).

Мне кажется лучше использовать 1 вариант, возможностей в нем не мало. Я, например, в большинстве случаев вообще отлаживаю, анализируя код в уме. Хотя это и трудно, но иначе ни как.

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

Хмм...

Мне показалось или я где-то видел, что в качестве одного из применений Kolibri предлагалось обучение программированию на ассемблере? Если так, то цифру 1% следует сильно увеличить.
В общем, буду писать отладчик 3-кольца. Начинающим программистам на ассемблере нужен именно такой отладчик. Главный дебаггер ядра halyavin прекрасно работает с Bochsdbg (+fasmdbg для генерации отладочной инфы), мнение Mario79 понятно, остальные, видимо, воздержались и их мнения уже не учитываются. Отладчик 0-кольца в текущих условиях писать сложно; и есть bochs. А вот обычные приложения bochs'ом отлаживать практически невозможно, а MeOsDebug некоторых вещей не поддерживает.

diamond
Не выдергивай фразу из контекста. Я писал про Винду. Весь первый абзац.
В случае с Колибри естественно, что около 50% (а возможно и больше) ее постоянных пользователей являются программистами. Именно потому у нас пока так мало пользователей - мы не можем предложить им того, чего не реализовано в других ОС. Мы даже не можем предложить им огромной части того, что реализовано в других ОС.
А по факту непрограммисту по фигу, в какой ОС он работает, если она удовлетворяет почти все его потребности. Даже более того давно уже высказывается мнение, что непрограммисты вообще не должны знать даже название ОС. Вернее произойдет монополия одной ОС.

Mario79
Я сразу не понял. Приношу извинения.
all
Кто-нибудь что-нибудь имеет против следующего добавления к системным функциям? Если нет, то просьба halyavin'у через несколько дней залить соответствующие (посланные по почте) изменения.

Функция ядра 40 - установить маску для ожидаемых событий
...
бит 8 (маска 0x100): сообщение отладки
Функции ядра 10, 11, 23: могут дополнительно возвращать eax=9 - получено (новое) сообщение отладки.

Функция ядра 58 - доступ к файловой системе
...
структура fileinfo для запуска процесса:
dd 16 ; 16 = запустить программу
dd flags ; поле флагов:
; бит 0: запустить процесс как отлаживаемый
dd param ; 0 или указатель на строку с параметрами (max 256 символов)
dd 0 ; не используется
dd 0x10000 ; память для работы ОС - 4096 байт
db '/HD/1/MENUET/APPS/FIRE',0 ; ASCIIZ-строка с полным путем к файлу
результат: eax = pid или 0xfffffff0+ ошибка
Если процесс запускается как отлаживаемый, он создается в замороженном состоянии;
для запуска используйте функцию eax=69,ebx=5.

Функция ядра 69 - отладка
У процесса может быть только один отладчик, его уведомляют о происходящих исключениях.
Один процесс может отлаживать несколько разных.
При завершении отладчика прибиваются все отлаживаемые процессы. Если отладчик
этого не хочет, он должен предварительно отключиться подфункцией 2.

Пока не реализовано слежение за новыми процессами и потоками.

Все подфункции применимы только к процессам/потокам, запущенным из текущего
функцией 58 с установленным флагом отладки
/* и процессам/потокам, запущенных из отлаживаемого при условии,
что был установлен соответствующий флаг при создании процесса. - пока не поддерживается */

ebx = 0 - определить область данных для отладочных сообщений
ecx = указатель
Структура области данных:
dd N = размер буфера (не считая этого заголовка)
dd занято в буфере
times N db буфер
Если поле размера отрицательно, буфер считается заблокированным и при поступлении нового
сообщения система будет ждать. Для синхронизации обрамляйте всю работу с буфером операциями
блокировки/разблокировки типа neg [bufsize].
Данные в буфере трактуются как массив элементов переменной длины. В любом сообщении присутствуют
первые два dword'а: код сообщения и идентификатор вызвавшего его процесса. Для некоторых
кодов могут присутствовать дополнительные данные, определяемые кодом.
Коды отладочных сообщений:
1 = исключение
дополнительно передается dword-номер исключения
процесс приостановлен
2 = процесс завершился
приходит при любом завершении: как через системную функцию -1,
так и при "убийстве" любым другим процессом (в том числе самим отладчиком)


ebx = 1 - получить состояние регистров отлаживаемого процесса
ecx = идентификатор
esi = указатель на структуру контекста
edx = длина структуры контекста (должно быть 28h=40 байт)
Контекст процесса: (FPU пока не поддерживается)
dd eip
dd eflags
dd eax
dd ecx
dd edx
dd ebx
dd esp
dd ebp
dd esi
dd edi
Если процесс выполняет код 0-кольца, возвращается состояние регистров 3-кольца.

ebx = 2 - установить состояние регистров отлаживаемого процесса
ecx = идентификатор
esi = указатель на структуру контекста
edx = длина структуры контекста (должно быть 28h=40 байт)
Если процесс выполняет код 0-кольца, устанавливается состояние регистров 3-кольца.

ebx = 3 - отключиться от отлаживаемого процесса
ecx = идентификатор
если процесс был приостановлен, он возобновляет выполнение
ebx = 4 - приостановить отлаживаемый процесс
ecx = идентификатор

ebx = 5 - возобновить выполнение отлаживаемого процесса
ecx = идентификатор

ebx = 6 - прочитать из памяти отлаживаемого процесса
ecx = идентификатор
edi = указатель на буфер
edx = сколько байт читать
esi = адрес памяти в другом процессе
На выходе: eax = число прочитанных байт

ebx = 7 - записать в память отлаживаемого процесса
ecx = идентификатор
edi = указатель на буфер
edx = сколько байт писать
esi = адрес памяти в другом процессе
На выходе: eax = число записанных байт

ebx = 8 - завершить отлаживаемый процесс
ecx = идентификатор
(Есть еще подфункция 2 функции 18, но она принимает не идентификатор, а номер)

diamond
Было бы неплохо, если бы ты написал статью после внедрения с примерами конкретной отладки.

Mario79
По поводу отладки - скоро будет сам отладчик (с исходниками, естественно). А на работу каких-либо других компонентов системы это не влияет никак.

Версия 0.1:
http://shade.msu.ru/~msu-se/mtdbg - программа
http://shade.msu.ru/~msu-se/mtdbg.rar - исходник
Тестируйте...

diamond меня всегда удивляет с хорошей стороны, никогда не ворчит, никогда не скажет лишнего, спросит только "Надо?", а потом говорит "Забирайте" Просто молодец!

Это еще одна надежда для Kolibri... Так держать, diamond!

diamond
Надо написать подробную доку.
Может я тупой, но у меня такие результаты:
load fasm - отладчик завершается и все
load tinypad - - отладчик завершается и все
load calc - - отладчик завершается и все
Не понимаю...

Mario79
Это один из багов Правильно: load /rd/1/fasm или load /rd/1/tinypad или load /rd/1/calc.

Причем это баг функции 58 - при запуске (подфункция 16) приложения с именем типа "mfar" (вместо "/rd/1/mfar") ядро возвращает, что процесс успешно загружен.
Несколько багов исправлены, исправленную версию качать там же.

Исправлен баг функции 58. Скорректированы возвращаемые значения для подфункции 16, см. комментарии в fs.inc. Немного обновлен mtdbg, теперь он показывает причину ошибки при обломе загрузки. Бинарник лежит там же, исходник на этот раз имеет расширение .7z. Извиняюсь за отсутствие синхронизации с выходом дистриба, но я о нем понятия не имел. Впрочем, в дистриб mtdbg не входит, а остальные программы нечувствительны к произведенным изменениям.

diamond
Не страшно, думаю, ты как раз к следующему дистрибутиву исправишь еще багов и напишешь таки подробную доку.