Для поддержания ракетного щита нашей великой родины
понадобилось написать отладчик для отечественного процессора
с оригинальной системой команд. Кто-нибудь знает, как это делается?
Знаю, что нужно к gdb написать несколько функций.
Но что должны конкретно делать эти функции?
Может быть есть какая-нибудь книжка (или статья), где это толково изложено?
(Документацию самого gdb смотрел, там изложено бестолково).
Ну вот тебе две ссылки, найденные просто навскидку:
A>Может быть есть какая-нибудь книжка (или статья), где это толково изложено? A>(Документацию самого gdb смотрел, там изложено бестолково).
A>Товарищи!
A>Для поддержания ракетного щита нашей великой родины A>понадобилось написать отладчик для отечественного процессора A>с оригинальной системой команд. Кто-нибудь знает, как это делается? A>
A>Знаю, что нужно к gdb написать несколько
Совсем не так. И зачем тебе это говно ? Они сами свой протокол особо не соблюдают между версиями.
Для начала надо понять КАК твой отладчик должен работать. Как организуется single stepping, точки останова — на адрес, на событие, надо ли отлаживать ПЗУ, какие есть кольца защиты и как их можно использовать (например юзермодный код гораздо легче отлаживать будучи монитором, и когда мониторный код отлаживать не надо). Какой abi у платформы, как раскручивается стек. Поддержка крешдапмов. Формат отладочной информации — это чтобы конвертировать строки и имена переменных в адреса и смещения при source-level отладке.
А вообще может там jtag есть, это резко и сильно упрощает дело.
Здравствуйте, IID, Вы писали:
A>>Знаю, что нужно к gdb написать несколько
IID>Совсем не так. И зачем тебе это говно ? Они сами свой протокол особо не соблюдают между версиями.
О как. Я с GDB никогда не работал, но всегда думал, что это такой универсальный, платформо-независимый отладчик, к которому достаточно лишь подключить интерфейсный модуль для новой платформы, и вуаля...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>к которому достаточно лишь подключить интерфейсный модуль для новой платформы, и вуаля...
Перечисленное мной выше само по себе не родится ведь, так ?
И в итоге остаётся от того GDB только транспорт (текстовый кстати) между сервером и клиентом. Да возможность source-level отладки нахаляву, если отладочкая информация в совместимом виде. В какой-нибудь связке QtCreator + GDB или VSCode + плагин или VisualStudio + MS MI Engine.
Хотя его же можно сделать и без всего этого. Пример — отладчик для Squirrel, использует Standalone шкурку от 2008 студии + своё раширение.
Здравствуйте, IID, Вы писали:
IID>Совсем не так. И зачем тебе это говно ? Они сами свой протокол особо не соблюдают между версиями.
IID>Для начала надо понять КАК твой отладчик должен работать.
Нет, для начала надо понять, как отладчик должен взаимодействовать с человеком. Потому что с этой точки зрения все отладчики, которые мне доводилось видеть — УГ.
IID>Как организуется single stepping, точки останова — на адрес, на событие, надо ли отлаживать ПЗУ, какие есть кольца защиты и как их можно использовать (например юзермодный код гораздо легче отлаживать будучи монитором, и когда мониторный код отлаживать не надо). Какой abi у платформы, как раскручивается стек. Поддержка крешдапмов. Формат отладочной информации — это чтобы конвертировать строки и имена переменных в адреса и смещения при source-level отладке.
У них там секретный военный линух и все такое. Он вполне себе host, а не target.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>У них там секретный военный линух и все такое.
ЕМ>В нем sin(x) сразу достигает четырех, или в мирное время ограничено до двух?
Эта информация отсутствует в открытых источниках. Кстати, а Вы почему интересуетесь?
Здравствуйте, Pzz, Вы писали:
ЕМ>>В нем sin(x) сразу достигает четырех, или в мирное время ограничено до двух?
Pzz>Эта информация отсутствует в открытых источниках. Кстати, а Вы почему интересуетесь?
Товарищ майор, я больше не буду, не присылайте больше ваших сотрудников.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, alpha21264, Вы писали:
A>>Знаю, что нужно к gdb написать несколько
IID>Совсем не так. И зачем тебе это говно ? Они сами свой протокол особо не соблюдают между версиями.
Да вот я уже пришёл к выводу, что от этого говна вреда больше, чем пользы.
Поэтому хочу написать свой отладчик, пусть и примитивный, но без тонн лишнего кода, который глючит.
IID>Для начала надо понять КАК твой отладчик должен работать. Как организуется single stepping, точки останова — на адрес, на событие, надо ли отлаживать ПЗУ, какие есть кольца защиты и как их можно использовать (например юзермодный код гораздо легче отлаживать будучи монитором, и когда мониторный код отлаживать не надо). Какой abi у платформы, как раскручивается стек. Поддержка крешдапмов. Формат отладочной информации — это чтобы конвертировать строки и имена переменных в адреса и смещения при source-level отладке.
Ну вот это всё я и хочу узнать. Хотя бы как это делается на идейном уровне.
Сейчас я могу (с помощью gdb) запускать программу, ставить точку останова и запускать программу дальше.
Даже могу просмотреть некоторые (почему-то не все) переменные. Для полного счастья не хватает хождения по стеку.
Как это хотя бы теоретически должно происходить?
Я так понимаю, что должны как-то взаимодействовать три сущности:
1) отладчик,
2) ядро (именно оно исполняет ptrace, и если ptrace чего-то не умеет, то отладчик бессилен)
3) сама отлаживаемая программа
4) У компилятора есть какие-нибудь обязанности в этом процессе?
Вроде бы он в dwarf что-то должен положить.
Собственно, в чём проблема — есть какие-то неявные договорённости между отладчиком и ядром,
и глядя только в код отладчика замысел понять невозможно.
Отсюда вопрос — может про это кто-то что-то знает (где-то это написано)?
Здравствуйте, Pzz, Вы писали:
IID>>Для начала надо понять КАК твой отладчик должен работать.
Pzz>Нет, для начала надо понять, как отладчик должен взаимодействовать с человеком. Потому что с этой точки зрения все отладчики, которые мне доводилось видеть — УГ.
Вам бы, буханщикам, сперва самим воспользоваться этим невероятно ценным советом. 36 лет пилите свой GDB, а он как был куском кала, так и остался.
Когда-то, лет 5 назад, я был очень недоволен WinDbg. Его UI действительно ужасен. Но только до тех пор, пока не сталкиваешься с GDB. Тогда понимаешь, насколько глубоко дно.
Оспаде, даже pwndbg, морда для GDB от энтузиастов, и та — слизанный с Soft ICE интерфейс. Который загнулся 14 лет назад.
Примеры хороших интерфейсов — Visual Studio, OllyDbg. Да даже бесплатный VSCode даст 100 очков вперёд этому вашему GDB.
Возвращаясь к теме топика — ТСу надо написать отладчик, а не UI для отладчика. Функционал отладчиков известен и устрясён уже лет 30 как. Так что не надо нам тут зубы заговаривать
Здравствуйте, alpha21264, Вы писали:
A>Даже могу просмотреть некоторые (почему-то не все) переменные.
Переменная может быть optimized out, и ты её не сможешь читать как ячейку в памяти. Например она находится в регистре. Или вообще выкинута за ненадобностью в ходе оптимизаций.
A>Для полного счастья не хватает хождения по стеку.
Чтобы ходить по стеку надо знать как этот стек устроен у данного компилятора.
Хорошо если в стек ВСЕГДА кладётся фрейм предыдущего стека. Тогда проблемы вообще нет. Вот как поступает буханка в ядре:
struct stackframe frame;
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_stack_pointer;
frame.pc = (unsigned long)caller;
do {
int ret = unwind_frame(&frame);
if (ret < 0)
break;
(void*)frame.pc; // <----
Если же вмешивается оптимизатор — всё рассыпается.
A>Как это хотя бы теоретически должно происходить?
A>Я так понимаю, что должны как-то взаимодействовать три сущности: A>1) отладчик, A>2) ядро (именно оно исполняет ptrace, и если ptrace чего-то не умеет, то отладчик бессилен)
Не обязательно.
Ты можешь трассировать чип аппаратно.
Или же полностью программно. На ZX-Spectrum ядра не было. А отладчики были. Причём они позволяли трассировать всё ОЗУ (за исключением 19 байт перемещаемого резидента) а также ПЗУ. Сам отладчик при этом находился в странице верхней памяти и в основное ОЗУ не отображался.
A>3) сама отлаживаемая программа A>4) У компилятора есть какие-нибудь обязанности в этом процессе? A> Вроде бы он в dwarf что-то должен положить.
Компилятор и отладчик должны быть тесно связаны. Чтобы отладчик умел правильно отображать параметры — он должен знать ABI. Чтобы раскручивать стек — про формирование фреймов компилятором. DWARF это уже отладочная инфа, для SourceLevel отладки (я про неё в первом посте писал)
По-сути тебе нужны следующие вещи:
— read/write памяти программы
— возможность установки breakpoint (аппаратный или прыжок на твой код, прыжок в монтор aka ядро).
— перехвата аппаратных исключений (win даёт userlevel программе шанс aka first chance exception, в *nix есть сигналы. Если ты в ядре — ты вообще царь и бог).
— возможность single step
В ARM вот сигнлстеппинга нет. И аппаратные BP могут быть не доступны в UserMode. Его можно эмулировать установкой BreakPoint, но тут же огребаешь кучу проблем.
Либо код из-под BP затираем-восттанавливаем, не паримся, но огребаем в многопотоке.
Либо его надо перенести в отдельное место, а тогда нужен dynamic дизассемблер.
Хотя бы на уровне:
1) длина инструкции
2) какие регистры модифицируются
3) в какие адреса памяти происходит доступ
4) происходит ли передача управления.
Здравствуйте, IID, Вы писали:
Pzz>>Нет, для начала надо понять, как отладчик должен взаимодействовать с человеком. Потому что с этой точки зрения все отладчики, которые мне доводилось видеть — УГ.
IID>Вам бы, буханщикам, сперва самим воспользоваться этим невероятно ценным советом. 36 лет пилите свой GDB, а он как был куском кала, так и остался.
Я не принимал участие в написании gdb. Если название cdb тебе чего-нибудь говорит (что вряд ли), то в нем есть изрядное количество моего кода.
IID>Возвращаясь к теме топика — ТСу надо написать отладчик, а не UI для отладчика. Функционал отладчиков известен и устрясён уже лет 30 как. Так что не надо нам тут зубы заговаривать
ТСу надо спортировать gdb на нестандартную архитектуру. Во всяком случае, запрос его был сформулирован именно так.
Здравствуйте, alpha21264, Вы писали:
A>Да вот я уже пришёл к выводу, что от этого говна вреда больше, чем пользы. A>Поэтому хочу написать свой отладчик, пусть и примитивный, но без тонн лишнего кода, который глючит.
По мне, так единственная польза от отладчика — core dumpы анализировать.
IID>>Для начала надо понять КАК твой отладчик должен работать. Как организуется single stepping, точки останова — на адрес, на событие, надо ли отлаживать ПЗУ, какие есть кольца защиты и как их можно использовать (например юзермодный код гораздо легче отлаживать будучи монитором, и когда мониторный код отлаживать не надо). Какой abi у платформы, как раскручивается стек. Поддержка крешдапмов. Формат отладочной информации — это чтобы конвертировать строки и имена переменных в адреса и смещения при source-level отладке.
A>Ну вот это всё я и хочу узнать. Хотя бы как это делается на идейном уровне. A>Сейчас я могу (с помощью gdb) запускать программу, ставить точку останова и запускать программу дальше. A>Даже могу просмотреть некоторые (почему-то не все) переменные. A>Для полного счастья не хватает хождения по стеку. A>Как это хотя бы теоретически должно происходить?
Почитай спецификацию DWARD. Она написана не ужасным языком, и когда ты ее прочтешь, тебе многое станет понятно.
