Как прикрутить отладчик GDB к своему микроконтроллеру?, Отладка Си-кода с помощью GDB в процессоре нестандартной архитектуры. Опции

[tema13tema]

Уважаемые ГУРУ и МАГИ форума!

Описание:
Есть проц собственной разработки, под который на фирме программировали до сих пор на асме. Стала задача портировать компилятор Си. После некоторого времени капания в сети нашел проект LLVM (http://llvm.org/). Идея проста: под GCC-фронтэнд компилятора компилирует в промежуточный код, который не привязан к платформе, а бекэнд (который нужно написать своими ручками) переводит этот промежуточный код уже непосредственно в ассемблер или в бинарный код для процессора. Эта часть успешно была мной реализована, Си успешно компилируется в асм.

Проблема:
Но есть острая необходимость в возможности отладки исходного Си-кода. Изучил много доки по GDB, по его удаленной отладке (target remote ... ). Насколько я понимаю, GDB должен знать архитектуру моего проца, т.е. регистры, стек и т.п. Это значит нужно что-то дописать в самом GDB? Что именно? Или сам компилятор должен в исполняемый код добавить эту информацию для GDB? (так нет, при удаленной отладке не нужна даже таблица символов в исполняемом коде )
Просмотрел львиную долю форума, много тем по отладке, но пока меня ничто не натолкнуло куда мне двигаться дальше, в каком направлении рыть.

Буду благодарен любой помощи!

[Make_Pic]

Уважаемые ГУРУ и МАГИ форума!

Описание:
Есть проц собственной разработки, под который на фирме программировали до сих пор на асме. Стала задача портировать компилятор Си. После некоторого времени капания в сети нашел проект LLVM (http://llvm.org/). Идея проста: под GCC-фронтэнд компилятора компилирует в промежуточный код, который не привязан к платформе, а бекэнд (который нужно написать своими ручками) переводит этот промежуточный код уже непосредственно в ассемблер или в бинарный код для процессора. Эта часть успешно была мной реализована, Си успешно компилируется в асм.

Проблема:
Но есть острая необходимость в возможности отладки исходного Си-кода. Изучил много доки по GDB, по его удаленной отладке (target remote ... ). Насколько я понимаю, GDB должен знать архитектуру моего проца, т.е. регистры, стек и т.п. Это значит нужно что-то дописать в самом GDB? Что именно? Или сам компилятор должен в исполняемый код добавить эту информацию для GDB? (так нет, при удаленной отладке не нужна даже таблица символов в исполняемом коде )
Просмотрел львиную долю форума, много тем по отладке, но пока меня ничто не натолкнуло куда мне двигаться дальше, в каком направлении рыть.

Буду благодарен любой помощи!

Что же за хитрый самопальный контроллер у вас? Правильнее было использовать уже существующую архитектуру и добавить в нее то что вам очень так нужно в последствии расширив GCC собственной либой.

Но вернемся к вашему вопросу: вы отлаживать хотите на вашем собственно испеченном асме? Сразу скажу - неудобно, если изначально пишете на СИ. Но если так надо - то в вашем случае лучше написать свой дебагер - вам и карты в руки, так как архитектура контроллера - ваше детище! Что касается GDB, то он всю отладочную информацию берет из объектных файлов ELF или COFF. Описание этих форматов есть в инете. Но в вашем случае с двойной компиляцией это не пройдет. Посему или писать свой GNU компилятор (попрощайтесь с семьей, если она у вас есть) или перейти к первому абзацу моего сообщения.

[Сергей Борщ]

Насколько я понимаю, GDB должен знать архитектуру моего проца, т.е. регистры, стек и т.п. Это значит нужно что-то дописать в самом GDB? Что именно?

В документации по GDB это описано. Может не совсем понятно и конкретно, но описано. Берите за основу файлы от любого более-менее похожего на ваш процессора и правьте их под свой.

Или сам компилятор должен в исполняемый код добавить эту информацию для GDB? (так нет, при удаленной отладке не нужна даже таблица символов в исполняемом коде )

Компилятор должен добавить отладочную информацию (в формате stabs или dwarf-2, последний перспективнее). При удаленной отладке на удаленном процессоре запускается исполняемый код, а на локальной машине в gdb загружается объектный файл из которого тот исполняемый код получен. Из объектного файла gdb получает таблицы символов, ссылки на позиции в файлах исходников, информацию о типах и все прочее. Без отладочной информации возможна отладка только дизассемблированного кода. Кстати, дизассемблер для gdb тоже придется дописать. Если вы писали его для binutils, то он просто копируется из binutils - там те же файлы.

[tema13tema]

Что же за хитрый самопальный контроллер у вас? Правильнее было использовать уже существующую архитектуру и добавить в нее то что вам очень так нужно в последствии расширив GCC собственной либой.

Но вернемся к вашему вопросу: вы отлаживать хотите на вашем собственно испеченном асме? Сразу скажу - неудобно, если изначально пишете на СИ. Но если так надо - то в вашем случае лучше написать свой дебагер - вам и карты в руки, так как архитектура контроллера - ваше детище! Что касается GDB, то он всю отладочную информацию берет из объектных файлов ELF или COFF. Описание этих форматов есть в инете. Но в вашем случае с двойной компиляцией это не пройдет. Посему или писать свой GNU компилятор (попрощайтесь с семьей, если она у вас есть) или перейти к первому абзацу моего сообщения.

Make_Pic , спасибо за ответ.
Поясню: Есть фирма Hilscher GmbH, давно разрабатывают свой чип - NetX, сейчас у них уже целая линейка. Основа ARM 9й серии, но к нему есть обвязка из нескольких одинаковых сопроцессоров (ХРЕС). ARMу доступны их все адреса и ресурсяы. Вот эти сопроцессоры как раз и самопальные Для ARM весь набор компилятор/отладчик соответственно есть, для сопроцессоров - нет.

Отлаживать хочу на собственном асме, неудобно, но так нужно)) Буду смотреть описание форматов ELF и COFF. Описание есть - разберусь. Думаю, это то, что мне и нужно, т.к. в промежуточный код при компиляции в DEBUG режиме добавляется отладочная информация, но в непонятном формате, но есть описание)))
Писать свой GNU компилятор не собираюсь, ведь LLVM это он и есть, уже готовый.

В документации по GDB это описано. Может не совсем понятно и конкретно, но описано. Берите за основу файлы от любого более-менее похожего на ваш процессора и правьте их под свой.Компилятор должен добавить отладочную информацию (в формате stabs или dwarf-2, последний перспективнее). При удаленной отладке на удаленном процессоре запускается исполняемый код, а на локальной машине в gdb загружается объектный файл из которого тот исполняемый код получен. Из объектного файла gdb получает таблицы символов, ссылки на позиции в файлах исходников, информацию о типах и все прочее. Без отладочной информации возможна отладка только дизассемблированного кода. Кстати, дизассемблер для gdb тоже придется дописать. Если вы писали его для binutils, то он просто копируется из binutils - там те же файлы.

Сергей, спасибо. Буду читать доку к GDB.

[klen]

0xff

первый опыт
когда я был курсантом первого курса нас отправили убирать морковку с полей под г.Серпухов. запомнился первый выход на поле....

утро. роса. туман. мокрая холодная ботва морковки рядками уходящая в плотный туман тянущий с Оки..
- А скоко нам убрать нада до обеда? - спросил наш курсовой офицер бригадира колхоза.
- Все поле. - сказал бригадир.

через тридцать минут подул ветер и туман рассеиля. У нас опустились руки и упали челюсти...
ряды морковки уходили в горизонт вмиесте с рекой Окой...


вторй опыт
написание тулсов (асма линкера препроцессора дизасма и тд) для кр1878ве1

третьего не будет - написание монументальных произведений это к Льву Толстому, я пас.

мораль. задача вполне реальная и даже принципиально не сложая. но..... для нереально упрямых. удачи!

[tema13tema]

Klen, про морковку занимательная история
А с отладчиком мне всё-равно нужно разбираться, деваться некуда