Доброго времени суток. Подскажите, чем и как собирать плагины к кроссу GCC? Если хостовым компилятором -- то как плагин узнает о специфичных для платформы типах (могут отличаться по размерам, например, int-ы у хоста и кросса), и не придётся ли собирать по новой как хостовый компилятор, так и кросс (subj собран под линуксом тамошним MinGW, а я сейчас на виндовсе). Если самим кроссом (на что намекают файлы в каталоге /lib/gcc/arm-none-eabi/4.7.4/plugin/include), то как кодогенератор под ARM будет кодогенерировать под самого себя, исполняющегося на x86?

fatlortroll, боюсь, что в такой постановке на Ваш вопрос никто не захочет отвечать.

Приведите, хотя бы, пример плагина. Что Вам не хватает в кросскомпиляторе? Какую функцию Вы хотите добавить?

Какая у Вас платформа target-а тоже хорошо бы указать.


З.Ы.: почему у Вас такой странный ник? Троллю могут и не помочь, по доброте душевной. Публика на этом форуме - очень серьезные дяди.

ибо товарисчь, сходимши по даденой им же ж самим ссылке, не в силАх прочитать докУмент How-to-build-toolchain.pdf

От кросса мне хотелось бы создание файла конфигурации по C-шной структуре. Внутри контроллера живёт некое подобие MODBUS, и общается с внешним миром. Внешняя общалка использует сгенерированный файл с описанием данных и функций. Сейчас этот файл генерируется внешним скриптом, но скрипт не может знать, сколько байт в, например, int-е контроллера. Оттого и хочется генерировать файл плагином. Ему можно явно сказать sizeof(int), и размер посчитается без участия человека.

Целевая платформа -- STM32F373.

Ник -- привет из прошлого. Он мне дорог, как память. :-)



How to build-то я прочитать могу, и даже прочитал. Но меня интересует техническая сторона вопроса. Придётся ли пересобирать с нуля ещё и хостовый компилятор? Откуда хостовый компилятор, если им собирать плагин, узнает размеры базовых типов платформы кросса? Зачем в каталогах кросса такие подробные include для создания плагинов? Не хочется биться лбом в стену -- может, рядом есть дверь, да я её не вижу.

В вещах, общающихся с внешним миром, нормальные люди не используют встроенные типы.
Для обеспечения детерминированности размеров полей пользуются <stdint.h>
В связи с чем -подозрение, что Вы вообще крайне далеки от программирования. Начните плз с более простых вопросов.
И собирать компилятор - задача нетривиальная, она к Вашему вопросу никаким боком не относится.

Что было в ТЗ, то и использую. Это уж не мне решать.

Внезапно, наружу могут отдаваться не только целочисленные, но и с плавающей точкой. В любом случае внешнему скрипту надо будет знать, сколько байт в том же uint16_t, то есть реализовывать часть парсера C / C++. А ещё POD-структуры наружу могут отдаваться. И массивы. С ними что прикажете делать?

Подозрения -- штука такая, сродни гаданию по юзерпику.

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

Ух-ты! Предыдущая реализация??? ;-)



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

Колоссально!©

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



Может, хватит флудить? Виктория, вот, убеждает меня, что тут исключительно серьёзные люди живут. Или вы тут так, проездом?

С размером данных вроде бы все понятно, так как эта информация у кросскомпилятора есть. Но, ведь, как я понимаю, нужна ещё конкретная инфа от контроллера о тегах и фукциональных кодах? Как это передать? Вытащить наружу таблицу символов линковщика? Не уверена, насколько это "красиво" и "колоссально"... Попробовать можно.

Нет, этого, пожалуй, не требуется. Если очень кратко -- то структура в контроллере содержит следующие поля: номер, под которым структура значится в массиве; адрес переменной (или функции), приведённый к void*; доступ к переменной (функции) -- чтение/запись/выполнение; длина в байтах переменной (для функции неактуально). В сгенерированный файл пишется: имя переменной (или функции); идентификация поля, как переменной, или функции; номер структуры; кодовое обозначение типа данных для переменной; длина переменной в байтах.
Уф... Вроде, всё. Из этого файла общалка формирует запросы к контроллеру, а тот пытается их обработать в соответствии с полями структуры.

Вообще-то упомянутые вами типы данных строго определены стандартом. Во floate 4 байта на всех платформах, а в uint16_t 16 бит (2 байта) тоже на всех платформах. Потому что эти типы вводились как раз для переносимости между платформами. Может отличаться только порядок байт.

ISO/IEC 9899

При помощи команды

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

float и double, если я не ошибаюсь, могут иметь одинаковый размер, а могут и разный. По крайней мере мне вспоминается, что на AVR sizeof(float) == sizeof(double). И опять же, не хочется выносить во внешний скрипт часть парсера C-C++, хочется отдать максимум работы компилятору.

Это зависит от длины байта
В военное время может достигать числа Пи