Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как прикрутить отладчик GDB к своему микроконтроллеру?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
tema13tema
Уважаемые ГУРУ и МАГИ форума!

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

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

Буду благодарен любой помощи!
Make_Pic
Цитата(tema13tema @ Jun 26 2009, 21:31) *
Уважаемые ГУРУ и МАГИ форума!

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

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

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


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

Но вернемся к вашему вопросу: вы отлаживать хотите на вашем собственно испеченном асме? Сразу скажу - неудобно, если изначально пишете на СИ. Но если так надо - то в вашем случае лучше написать свой дебагер - вам и карты в руки, так как архитектура контроллера - ваше детище! Что касается GDB, то он всю отладочную информацию берет из объектных файлов ELF или COFF. Описание этих форматов есть в инете. Но в вашем случае с двойной компиляцией это не пройдет. Посему или писать свой GNU компилятор (попрощайтесь с семьей, если она у вас есть) или перейти к первому абзацу моего сообщения.
Сергей Борщ
Цитата(tema13tema @ Jun 26 2009, 20:31) *
Насколько я понимаю, GDB должен знать архитектуру моего проца, т.е. регистры, стек и т.п. Это значит нужно что-то дописать в самом GDB? Что именно?
В документации по GDB это описано. Может не совсем понятно и конкретно, но описано. Берите за основу файлы от любого более-менее похожего на ваш процессора и правьте их под свой.
Цитата(tema13tema @ Jun 26 2009, 20:31) *
Или сам компилятор должен в исполняемый код добавить эту информацию для GDB? (так нет, при удаленной отладке не нужна даже таблица символов в исполняемом коде wassat.gif )
Компилятор должен добавить отладочную информацию (в формате stabs или dwarf-2, последний перспективнее). При удаленной отладке на удаленном процессоре запускается исполняемый код, а на локальной машине в gdb загружается объектный файл из которого тот исполняемый код получен. Из объектного файла gdb получает таблицы символов, ссылки на позиции в файлах исходников, информацию о типах и все прочее. Без отладочной информации возможна отладка только дизассемблированного кода. Кстати, дизассемблер для gdb тоже придется дописать. Если вы писали его для binutils, то он просто копируется из binutils - там те же файлы.
tema13tema
Цитата(Make_Pic @ Jun 27 2009, 10:22) *
Что же за хитрый самопальный контроллер у вас? Правильнее было использовать уже существующую архитектуру и добавить в нее то что вам очень так нужно в последствии расширив GCC собственной либой.

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


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

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

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


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

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

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

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


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

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

мораль. задача вполне реальная и даже принципиально не сложая. но..... для нереально упрямых. удачи!
tema13tema
Klen, про морковку занимательная история smile.gif
А с отладчиком мне всё-равно нужно разбираться, деваться некуда sad.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.