Доброго времени суток, гуру и форумчане!

Возникла острая необходимость в наборе binutils для своего проца. Сейчас существует просто perl-скрипт перевода ассемблер-кода в загружаемый бинарник.

Изучая многие ветки форума, неоднократно попадал на упоминания об опыте портирования binutils у участников.

Хотелось бы получить ценные советы, с чего начинать, что использовать, чтобы избежать глупых ошибок и затратить меньше времени на портирование.

Как я понимаю, хорошо начинать с существующего примера. Рекомендуют M32R - в описании к CGEN. Насколько оправдано использование CGEN?


Буду благодарен любым советам/предложениям/замечаниям/рекомендациям!

Полноценный порт делал только diwil в рамках mspgcc. Остальные так, "киянкой обстукивали".
1) Выбрать наиболее похожий на ваш процессор прототип, под который порт уже есть.
2) Изучить описание BFD, особенно раздел BFD Front End.
3) Поиском по файлам исходников binutils находите упоминание прототипа и по аналогии добавляете свой процессор.
2.5) Возможно, надо списаться с основными разработчиками binutils чтобы вам выделили имя, под которым ваш процессор будет фигурировать в binutils.

Я портировал binutils под свой процессор (расширение 51-го до полной неузнаваемости, 8/16 бит инструкции, немеренная куча расширений до ортогональности операндов, косвенно-индексных адресаций, в т.ч. к стеку, и т.д.). CGEN не юзал, он мне ОЧЕНЬ не понравился, за основу взял AVR (tc-avr.c, opcode/avr.h)
Отвечу на любые конкретные вопросы, но не связанные с cgen

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

Ну это не совсем первоочередное. Точнее скажу так, не менее важное, но и не более, чем "gas/config/tc-xxx.c" модули, отвечающих за сам процесс ассемблирования. Я начинал с разбирательства в том, как добавить новую ISA, сделав на базе того же AVR еще один процессор, полностью его повторяющий. А потом - в путь, править под себя.

ЗЫ
Кстати я не до конца портировал, я на дизассемблер забил. А все остальное - по полной программе.

SM, а дизассемблер у отладчика GDB как-то опирается на дизассемблер из binutils? Или GDB использует только структуру BFD из binutils?

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

Да, он там тот же самый. Т.е переносится в GDB путем копирования файла из binutils целиком.

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

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

Сергей, я остановился на некотором промежуточном этапе портирования GCC компилятора (на базе проекта LLVM).
Задача подключить отладчик (я задавал вопрос по этому поводу: http://electronix.ru/forum/index.php?showtopic=64554. Судьба заставляет меня вернуться в этот проект). А так как он очень тесно связан с пакетом binutils и берет его составные части, то было бы замечательно портировать всю стандартную цепочку инструментов

P.S. Нашел твою ветку по вопросу портирования binutils (http://electronix.ru/forum/index.php?showtopic=32783)

Извиняюсь, SM твоя ветка по вопросу портирования binutils (http://electronix.ru/forum/index.php?showtopic=32783)

Я тоже Сергей Так что и так все в порядке....

1. скорее всего начать просмотра файла tc-xxx.c для известного проца. немного могу подсказать про msp430.
2. BFD front-end надо б изучить, но это не совсем обязательно для начала... Во всяком случае если архитектура статическая, то достаточно просто просмотреть соответствующие исходники для любого известного проца.
3. с CGEN лучше не заморачиваться - будет очень тяжело отлаживать потом код собственно ассемблера. тоже касается и релаксов - лучше пока не трогать их.
4. накатать дизассемблер. Это проще чем п. 1-3, ибо он обязательно понадобится для отладки когда будет написан ассемблер.

diwil, спасибо.

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