[fatlortroll 0]

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

[Виктория 0]

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

 

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

 

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

 

 

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

[_Pasha 0]

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

:a14:

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

[fatlortroll 0]

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

 

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

 

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

 

:a14:

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

 

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

[_Pasha 0]

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

 

В вещах, общающихся с внешним миром, нормальные люди не используют встроенные типы.

Для обеспечения детерминированности размеров полей пользуются <stdint.h>

В связи с чем -подозрение, что Вы вообще крайне далеки от программирования. Начните плз с более простых вопросов.

И собирать компилятор - задача нетривиальная, она к Вашему вопросу никаким боком не относится.

[fatlortroll 0]

В вещах, общающихся с внешним миром, нормальные люди не используют встроенные типы.

Для обеспечения детерминированности размеров полей пользуются <stdint.h>

В связи с чем -подозрение, что Вы вообще крайне далеки от программирования. Начните плз с более простых вопросов.

И собирать компилятор - задача нетривиальная, она к Вашему вопросу никаким боком не относится.

 

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

 

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

 

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

 

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

[Виктория 0]

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

 

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

 

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

 

То есть плагин должен сгенерировать некий файл данных?

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

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

 

 

[_Pasha 0]

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

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

[fatlortroll 0]

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

 

Не понял, о чём Вы, но на всяк.случ. :-)

 

То есть плагин должен сгенерировать некий файл данных?

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

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

 

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

 

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

 

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

[Виктория 0]

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

 

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

[fatlortroll 0]

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

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

Уф... Вроде, всё. Из этого файла общалка формирует запросы к контроллеру, а тот пытается их обработать в соответствии с полями структуры.

[msalov 0]

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

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

 

ISO/IEC 9899

7.18.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with width N, no padding

bits, and a two’s complement representation. Thus, int8_t denotes a signed integer

type with a width of exactly 8 bits.

2 The typedef name uintN_t designates an unsigned integer type with width N. Thus,

uint24_t denotes an unsigned integer type with a width of exactly 24 bits.

[AHTOXA 14]

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

 

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

    arm-none-eabi-gcc -dM -E - < /dev/null

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

 

[fatlortroll 0]

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

 

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

 

[MrYuran 16]

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

Это зависит от длины байта :)

В военное время может достигать числа Пи