Написание плагинов к кросскомпилятору GCC Опции

[fatlortroll]

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

[Виктория]

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

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

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


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

[fatlortroll]

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

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

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

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

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

[_Pasha]

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

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

[fatlortroll]

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

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

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

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

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

[MrYuran]

В любом случае внешнему скрипту надо будет знать, сколько байт в том же uint16_t

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

[fatlortroll]

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

Смех смехом, но я про то, что в скрипт придётся пихать информацию о том, что uint16_t весит 16 бит, а uint8_t таки 8, т.е. делать вручную то, что компилятор уже знает. Лениво мне за компилятор работать, вот и пытаюсь оценить, что обойдётся "меньшей кровью" -- писать плагин к компилятору, или писать кусок компилятора.

Дык я же и говорю: хватит флудить. Вместо того, чтобы выложить куски проблемного кода, Вы пытаетесь напеть Карузо по телеграфу

OK, в понедельник зашлю куски кода.

[AHTOXA]

Лениво мне за компилятор работать, вот и пытаюсь оценить, что обойдётся "меньшей кровью" -- писать плагин к компилятору, или писать кусок компилятора.

Вы, вероятно, пропустили моё сообщение на прошлой странице. Там вариант с самой малой кровью.

[fatlortroll]

Вы, вероятно, пропустили моё сообщение на прошлой странице. Там вариант с самой малой кровью.

Прошу прощения, банально позабыл. Пятница была, всё же. :-) Вот куски кода:

Код

struct
{
   uint8_t first;
   uint8_t second;
   uint8_t third;
} TestStruct;
const int16_t TestInteger = 9000;
float TestFloat;

struct
{
   const char      command; // Номер переменной
   const void*     addr;        // Указатель на переменную, приведённый к void*
   const char      access;     // Доступ к переменной (чтение/запись)
   const char      len;          // Размер переменной (в байтах), и, после '*', количество подобных переменных в массиве/структуре
} const ptable[] =
{
   //!PT_BEGIN
   {0x00, (void*) &TestStruct,   A_R | A_W, 1 * 3}, //              "TestStruct"
   {0x01, (void*) &TestInteger, A_R,           2},      // (signed) "TestInteger"
   {0xF0, (void*) &TestFloat,     A_R | A_W, }         // (float)    "TestFloat or another text"
};

Поскольку указатель на переменную кастуется к void*, то скрипту надо узнать её тип, и размер. Сейчас они явно указываются в самой структуре и комментарии, но есть вероятность ошибиться, или просто забыть обновить информацию после смены типа переменной, или размера массива. Вот я и захотел это дело автоматизировать. А поскольку лучше компилятора никто не знает, что творится в коде -- отдать эту работу ему.
Ну и просто интересно стало, как же пишутся плагины на кросскомпилятор.

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

Идея интересная, спасибо. Но в выхлопе map-файла указывается только общий размер массива/структуры. Есть ли возможность попросить у компилятора более подробную информацию о них? Размеры полей структуры, размер элемента массива.