OberonCore

Теперь могу уверенно сказать, что отладчик под А2 сделать не очень сложно

А скачать можно?

У кого-нибудь есть связь с автором?

См.
https://github.com/metacore/A2Community

в подкаталоге:
Work\Debugger\

debugger.doc
DebuggerBase.Mod
DebugInfo.Mod
I386.Debugger.Mod
WMHexEditor.Mod


viewtopic.php?f=61&t=6372&p=107141#p107139


Возможно, для Debugger потребуется

A2OS 6599
https://github.com/metacore/A2OS/tree/9 ... 5d93589c6c

или

http://sage.com.ua/ru.shtml?e1l0

Спасибо!

Богдан прислал мне архив следующего содержания:

Архив прилагается. Пытаюсь собрать его с упомянутой версией A2OS 6599, для этого
скачал эту версию, распаковал архив к исходникам и пересобираю А2 по процедуре, которая описана здесь (её я когда-то раньше вывел не помню как: http://вики-ч115.программирование-по-русски.рф/Ч115/Сборка). В FoxAMDBackend.Mod он ругается на отсутствие Backend.Registers.

Версия FoxAMDBackend.Mod изрядно отличается от приведённого vmtutby.

Моя идея состоит в том, что нужно сначала заставить этот отладчик работать в той версии, в которой он уже когда-то работал, а уже потом пытаться его модернизировать под современную A2OS (если это вообще кому-нибудь интересно). Аналогичным образом Иван Денисов оживил отладчик для ББЦБ и вообще это методически правильно.

backend.registers присутствуют в сборке 6602, которая моложе, чем 6599.

Также в архиве есть FoxBackend1.Mod, который явно является старой версией FoxAMDBackend, датируется 2014.11.30

В целом похоже на то, что нужно искать версию от осени 2014 года. На git-зеркале изменения есть только с 2015 года. Пользуюсь SVN, но сейчас я на мобильном интернете, это получается медленно и дорого.

Нашёл такой репозиторий: https://github.com/egphilippov/A2OS_ForPullsToUpstream

В этом репозитории установил версию от 2014-07-04 с сообщением "rebuilt releases",
далее действовал по инструкции из WMDebugger.Tool, за исключением того, что вместо
FoxAMDBackend.Mod компилировал FoxAMDBackend1.Mod.

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

В общем, мои знания A2 малы, и времени у меня тоже нет. Проект интересный, но я его отложу. Думаю, лучше всего будет, если Богдан всё же оживит отладчик. Тогда появятся предпосылки для его портирования на более новые версии. В текущем состоянии непонятно, работает ли данная версия или нет. Богдан написал, что не уверен в том, что присланные файлы составляют полный и работающий набор. Поэтому сначала нужно продиагностировать и починить. Не зная деталей устройства и не располагая большими кусками времени, я за это вряд ли готов взяться сейчас.

Он запустился. Не помню, что я делал не так, но раньше не запускался. В инструкции есть нюансы (если делать прямо по ней, то вряд ли что-нибудь выйдет).

Нюансы таковы:

- взять версию от 2014-07-04
- вместо FoxAmdBackend брать FoxAmdBackend1.mod
- компилировать TestDbg уже после выгрузки FoxAMDBackend, т.к. только после замены этого модуля начинает генерироваться файл .Dpi с отладочной информацией
- далее открываем WMDebuggerTool.Open TestDbg.Mod
- ставим точку останова в начале TestTry (Ctrl+F8)
- выполняем откуда-нибудь команду TestDbg.TestTry

Качество я бы обозначил как "прототип", поскольку при хождении по строкам с помощью Step Into/Step Over наблюдались всеразличные аномалии. Но всё равно результат очень впечатляющий.

Может как-раз FoxAmdBackend висел в памяти

Не, это уже после пары перезагрузок. В общем, есть что чинить, но уже не сегодня, наверное.

Какая теория лежит в основе этого отладчика? Вроде отладчик обычно - это стороннее приложение, отличающееся от исследуемой программы. А тут программа патчит сама себя. Это вообще в принципе может работать?

Ну, когда-то, только так и было.

Т.е. так можно, Вы хотите сказать? При этом возникает несколько вопросов. Вот хотя бы два:

* многопоточность (другой тред может выполнить код во время его изменения)
* отладчик может начать шагать по самому себе, коду оконной системы, ядру ОС и т.п. - это не страшно, если мы умеем идентифицировать то, что не подлежит пошаговой отладке. Но непохоже, что это сделано у Богдана, судя по результатам моей попытки зайти внутрь KernelLog.String.

Полез читать статьи... Если у кого-нибудь есть хорошая - поделитесь.

А зачем заходить внутрь KernelLog.String?

Просто по ошибке. Отладчик по идее должен быть надёжным инструментом, а не сараем с граблями

Тут люди в личке интересуются, как воспроизвести мои результаты. Пока что полной инструкции нет. Ради такого, наверное, можно и релиз пересобрать, на этой неделе постараюсь это сделать.


Примерно должно работать так:

Качаем https://gitlab.com/budden/jaos/commit/e ... 5bc9503bbd

Пересобираем систему (руководство тут: http://вики-ч115.программирование-по-русски.рф/Ч115/Сборка) - при этом ни TFPET, ни отладчик НЕ будут собраны, символьные файлы для TFPET НЕ будут созданы.

Собираем отладчик согласно Debugger.Tool

Дальше см. выше. вот здесь: viewtopic.php?f=22&t=1410&p=109548#p109529

Это всё без гарантии, сейчас некогда проверить. Когда сделаю - отпишу.

Статьи про отладчик пока такие:

https://xakep.ru/2003/07/15/19158/
https://habr.com/ru/post/178159/

Осознаю, что они не лучше, но уж что есть.

Отладчик заработал в версии 6599, по сути дела ничего менять не пришлось. Теперь надо переходить на новый формат объектных файлов. Посоветуйте, с чего начать и куда копать.