свежак для Coretex-M3

довольно много свежего :
ветка gcc 4.5.0
новый релиз newlib 1.17.0

от себя добавил мультилиб специально оптимизированый под Cortex-M3, в нем немного поэксперементировал с оптимизацией
Недельку потестил на stm32f103rbt, крутим подтюненый FreeRTOS 5.2.0 c 6 задачками USB,UART, софтварный ARINC, debug trace facility... все работает без глюков.
пробуйте

http://www.klen.org/Files/DevTools/kgp_cor...1.0.20090413.7z

поскольку сборка только для кодогенерации под Cortex-M3 был проделан эксперемент : максимально компактный дистрибутив, для этого удалено все лишнее. В итоге сборка весит всего 7.07 мегабайт.

Что-то ругается он у меня, пишет



Пустой проект, никаких инклюдов.

а нельзя ли собирать и под Linux ?

2_AHTOXA
проверьте наличие файла libgcc.a в дериктории
ZZZ\lib\gcc\arm-kgp-elf\4.5.0\cortex-m3
где ZZZ - то куда Вы из архива все сложили.

2_ukpyr
в каком смысле под Linux, linux-target GCC или linux-host ?
короче для какой платформы код генерить это таргет, а на какой это хост.

хост конечно. Linux x86-32bit.
сейчас пользуюсь этим : http://www.codesourcery.com/sgpp/lite/arm/...?@template=lite

Хм. Всё заработало... Наверное я в прошлый раз плохо вычистил предыдущую версию:-)
Прошу прощения за ложную тревогу.

Продолжаю ковыряния:-) Дошёл до C++. Не работает



cc1plus-а нет в наборе. И почему 4.4.0 ?


Очень бы хотелось чтоб это заработало, потому что с Вашей сборкой у меня складываются отношения гораздо более удачно, чем со сборкой от CodeSourcery:)

------------
Ага, вот оно что. Вернул из заначки папки
\lib\gcc\arm-kgp-elf\4.4.0\
и
\libexec\gcc\arm-kgp-elf\4.4.0\

и файлы

\arm-kgp-elf\lib\libc.a
\arm-kgp-elf\lib\libm.a
\arm-kgp-elf\lib\libstdc++.a

- заработало. Даже ножкой дрыгает
Но меня немного смущает вся эта мешанина.

Не, это я поспешил. Объекты не создаются, конструкторы не вызываются... Ножкой дрыгает только до первого обращения к какому-либо объекту.

Объекты глобальные? Если да, то стартап свой или есть что-то в библиотеке? Если свой - есть ли в нем собственно вызов конструкторов?

Объекты глобальные. Стартап свой, вернее, из примера 4-BlinkLeds порта scmRTOS под STM32 под gcc. (который c http://mercurial.intuxication.org/hg/scmrtos-cm3-gcc). Конструкторы вызываются. При компиляции тулчейном от CodeSourcery (arm-none-eabi-) пример даже работает, правда только с оптимизацией -O0. Меня это смущает

А arm-kgp-elf- здесь оплошал. ( Или я )

не удивительно
я C++ ниразу не тестировал - тока C/fortran в реальных текущих разработках.
МЫСЛЬ испоьзовать С++ в микроконтроллерах просто ниразу НЕ ВЛЕЗЛА В МОЙ МОСК - РАЗМЕР ПРЕВЫШАЕТ ... куда катится мир?

итак. невызываются конструкторы? конструкторы каких объектов, как размещаете - cтатически или new?
посмотрим щас..

-------------------------------------------------

посмотрел:

#include "cplus_test.h"

#include "stm32f10x_gpio.h"

extern uint32_t _bss_end_ ;
uint32_t end = _bss_end_ ;

class blinker
{
private:
uint32_t ftimeout ;
uint32_t ftick_count ;

public:
blinker(uint32_t timeaut)
{
ftimeout = timeaut ;
}

~blinker()
{
};

void count_loop(uint32_t count)
{
ftick_count = xTaskGetTickCount();
for ( uint32_t acount = 0 ; acount < count ; acount ++ )
{
GPIOC->BRR = 0x0001000;
vTaskDelayUntil( &ftick_count , ftimeout);
GPIOC->BSRR = 0x0001000;
vTaskDelayUntil( &ftick_count , ftimeout);
}
}

void permanent_loop()
{
ftick_count = xTaskGetTickCount();
while(1)
{
GPIOC->BRR = 0x0001000;
vTaskDelayUntil( &ftick_count , ftimeout);
GPIOC->BSRR = 0x0001000;
vTaskDelayUntil( &ftick_count , ftimeout);
}
}
};


void test_constr_destr()
{
NOP();
blinker bl(50) ;
bl.count_loop(100) ;
NOP();
}

volatile portTickType tick_count ;
xTaskHandle cplus_debug_led_task_handle ;
void cplus_debug_led_task_code (void* param)
{
(void)param ;
blinker bl(250) ;
NOP();
test_constr_destr() ;
NOP();
bl.permanent_loop() ;


}

вот этот код работает
объекты статически создаются (в таком случае явно вызывается конструктор)
и даже работают
деструкторы не вызываются при выходе из функции в стеке которых они создались (причины на то есть)

тоесть глобальные оъекты можно использовать. тока зачем это нада? если все доелать(деструкторы) то в флеш еще потянется куча кода из libstdc++ и libsupc++ который обеспечивает например вызов деструкторов оъектов созданых в стеке функций... с этого места начнется полный завал.

Ненене:-) Если аккуратно, то ничего не превышает, даже наоборот! Минимальный пример scmRTOS сильно меньше минимального примера FreeRtos:) Объекты -- статические, глобальные. В смысле - совсем глобальные, когда объект объвлен вне функции. То есть должен создаваться при инициализации. Плюс маленькие объектики на стеке, типа TCritSect. Они, конечно, должны разрушаться при выходе из функции. По-моему, стандартные библиотеки тут не при делах.

Как компилировали? Голым свежаком 4.5.0? Или с либами от 4.4.0? То, что не вызываются деструкторы - это грустно. Если уж для MSP или даже для AVR это не является слишком тяжёлым бременем, то уж для АРМов-то это вообще семечки

Почему "доделывать"? Я не очень понимаю всю кухню, но разве в gcc этого нет?

Этот код тянется для деструкторов глобальных объектов. Почему именно этот код - не спрашивайте, не знаю. Там, действительно, подтягиваются и функции работы с файлами и куча еще всего кило на 20 примерно. Но обходится это довольно просто - не нужно делать деструкторы в глобальных объектах. Ибо они и не нужны - нормальная embedded-программа из main() не выходит и, значит, деструкторы никогда и не будут вызваны.

по поводу деструкторов погляжу как это все работает.

я уверен что все работает тока нада уметь ему об этом сказать!

потратил время исследования вопросов from AHTOXA

как и я думал все работает, а именно:
глобальные объекты работают.
локальыне на стеке работают
динамические оъекты ТОЖЕ работают (new/delete). сделел обертки для api FreeRTOS, собрал и протестил на олимексовской STM32-H103

под словом работают имеется ввиду вызов конструктора и деструктора в соответствующие моменты.

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

в ближайште дни выложу свежак в котором будет новый фича - оптимизатор циклов Graphite. заодно распишу че де как C++ заюзать.

Ну, вы немного лукавите конечно, ибо в последнем свежаке нет нужных либ и cc1plus.exe, но новость всё равно радостная:-)


Жду с нетерпением

не лувлю!
это у вас он свежак, а у меня он уже лежалая колбаса

Klen, можете собрать ветку 4.5 для MIPS ELF под Win32 хост?

ок.

Свежак для ARM
все компоненты сегодняшние 20090616:
binutils
gcc
gdb
newlib
oocd

www.klen.org/Files/DevTools/kgp_arm-elf-bu2.19.51_20090616-gcc4.5.0_20090616-gdb6.8.0_20090616-newlib1.16.0.20090616-oocd_20090616.7z

протестил на терровском махаоне - FreeRTOS, 3 задачи для светодиодов, 1 задача USB, 1 задача работа с SD карточкой, в целях тестиования код смешанный С/Fortran/C++ для проверки C++, как то работа конструкторов деструкторов new и delete и прочее. если кому нада выложу.

все target-либы собраны с флагами -g0 -Os -fomit-frame-pointer -ffunction-sections -fdata-sections -funroll-loops -fgraphite
для для cortex-m3 дополнително присунут -mfix-cortex-m3-ldrd

прикручен оптимизатор Graphite, который базируется на ClooG ( http://www.cloog.org/ ) , для задействования этой оптимизации нужно присунуть ключ -fgraphite

arm-kgp-elf-g++ не находит libiconv-2.dll



Конечно надо!

----------
Нашёл libiconv-2.dll вот тут. Вроде компилится теперь Будем смотреть дальше

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

СПАСИБО, уже скачал - свистните когда пересобирете.

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

обновил архив, добавил в него libiconv-2.dll, теперь не должно быть проблем



конечно!!
под богопристойную ось любой дурак собрать сможет, иначе как он вообще в нее залез??
когда то.... не сейчас, чтоб заставить работать Linux так как тебе нада, нельзя было пройти мимо gcc и сборки много чего прикручиваемого. поэтому мне трудно представить человека который рабоет на пингвине и не умеет собрать компиллер, че он вообще тогда от пингвина хочет? если я не прав то опишите мне как бывает по другому.

если нада то могу выкладывать архив и под линукс. всеравно сначала собирается версия под него а потом на нем кросс(таргет)-крос(хост)-тулсы под ВЫНь.


не у всех но у большинства
у меня убунта по умолчанию везде грузится, масдай для игрушек используеццо. и для разработки LockOn.

Было бы интерестно посмотреть на применяемые вами патчи и команды конфигурирования и компиляции под линукс

Вопрос 2 Klen.
У меня на работе народ пользует AVR Studio+последний WinAVR-20090313 - всем довольны (наверное).
Попросили прикрутить к AVR Studio Вашу сборку для AVR для тестирования.
На диске С: создал папку kgp_avr и скопировал туда Вашу сборку. Пути не прописывал.
В AVR Studio в External Tools убрал птицу UseWinAVR и прописал пути:
C:\kgp_avr\bin\avr-gcc.exe
make.exe у Вас не нашел - прописал C:\WinAVR\utils\bin\make.exe.
Запускаем на компиляцию проект работающий в WinAVR - получили:
avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--common Display total size for *COM* syms
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec tekhex binary ihex
make: *** [size] Error 1

из чего вроде понятно что в Вашей сборке нет для avr-size опции -- C.
Поясните как состыковать - хочется людям использовать стандартный make file AVR Studio.

Она идет отдельным патчем, который klen, по видимому, не наложил.Возьмите avr-size от WinAVR.

СПАСИБО - работает

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

Где в нете - не скажу. Есть в комплекте WinAVR в директории source.

Обнаружил непорядок с arm-kgp-elf (c++).
При использовании pure virtual функций

видимо подключается обработка exceptions, несмотря на флаг -fno-exceptions. В результате тянется malloc, который ругается на неопределённый символ end в _sbrk при линковке.

Хотелось бы этого избежать

Пока вышел из положения, объявив функции пустыми:


Но, может, я что-то упустил из виду?

а что стандарт говорит по этому поводу?

нада смотреть. скорее всего можно закомпилять libstdc++ так чтобы вообще исключений не использовались.

у меня в проектке есть virtual void bar() =0, и все линкуется. new и delete переопределены с использованием собственых malloc и free (свой менеждер кучи)

в любом случае спасибо. -fno-exception уменьшило размер .text в 2! раза век учись - дураком помреш,

Сомневаюсь, что там это есть. Как должна реагировать программа при вызове чисто виртуальной функции? Видимо в arm-gcc решили это через какой-то специальный эксепшн. Наверное это не считается обычным exception-ом, и поэтому не регулируется флагом -fno-exceptions. Само по себе это неважно, мне не нравится что тянется malloc. Кто его знает, сколько оно там отожрёт хипа

В msp-gcc использование pure virtual не тянет за собой malloc. Надо проверить на avr-gcc...


Даже не знаю, надо ли это... Думаю, что правильнее сделать, чтобы флаг -fno-exceptions действовал более чётко

что то я вообще сомневаюсь что для arm-elf вообще механизм эксепшенов реализован, так .. хвосты..
нада изучать вопрос и ковырятся...

Должна вызвать переопределенную версию этой функции. Функция переопределяется в классе-потомке. Если в классе-потомке функция не переопределена, то попытка создания объекта такого класса должна вызывать ошибку на этапе компиляции.

Точно, не компилится. Я почему-то был уверен, что там будет только warning. С дельфями перепутал
Тогда вообще непонятно, зачем цепляются исключения...

Оп-па... А что такое там с исключениями? А то я ими довольно широко пользуюсь, до сих пор на неприятности не нарывался... Считаете, на них нельзя так смело полагаться?

а у Вас все работает?
поделитесь опытом, как это происходит.

я довольно смутно представляю как работает С++ в плане исключений применительно к мелким контролерам. поэтому и написал что "неуверен...", нада было написать "незнаю"


2_AHTOXA
и должна вроде..
виртуальные функции работают, тут все ок. я имел ввиду только исключения! VMT как и положено в классах кладется по нулевому смещению, в классе потомке выбирается адресс из нее и все работает, у меня так обертка к задачам FreeRTOS сделана., функцияя кода задачи чисто виртуальная в базовом классе. А вот исключения дело темное!

например происходит обращение к NULL или вообще за диапазоном адресации какойнить шины - ядро генерит чтото типа bus abort а дальше то че? Вот тут видимо в обработчике и нада руками приуручивать механизм обработки исключений(библиотечные вызовы ) к конкретному механизму их генерации (аппаратные прервыания по косякам с памятью например).

для "не сильно мелких процов" типа ARM720... далее, хде есть MMU, Linux, и тд как я думаю эта прикрутка уже сделано в ядре линуха так как ядро и реализация libc конфигуртся под конкретный проц! я хрюнделем хорошо перерыд ядро линуха и uLibc когда делал девас на Тионе c EP9312, там видать в исходниках все это, и как системные вызовы прикручены к железке и тд.

для armv4 armv7 такого нет, может есть? и все работает как у alx2??? мне очень иньтересно

короче говоря я так это понимаю, если не прав то поправте.

в студию приглашаются специалисты по внутренней реализации C++ и отдельно к микрофону alx2, расказать как у него работают С++ исключения и собсно на чем?

Тут вы смешали в кучу исключения ядра ARM и плюсОвые исключения, которые генерятся программистом посредством ключевого слова throw.

Непонятно только, почему при упоминании чисто виртуальных функций подтягивается malloc? Вот что меня волнует более всего

Про исключения - Сергей Борщ уже сказал, это не те исключения.

Да, работает. throw исключение кидает, catch его ловит. Все в соответствии с правилами языка...

свежак для ARM
все кроме openocd 20090724
в OOCD чето сломали, падает при записи в флеш, поэтому положил предыдущую сборку.


www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090724.7z - обрезанна, для кортекса.
www.klen.org/Files/DevTools/kgp_arm_full_20090724.7z - полня


свежак для win32
также 20090724
www.klen.org/Files/DevTools/kgp_mingw32_20090724.7z

Посмотрел более предметно. Подтягивается не только malloc, подтягиваются-таки и исключения, как я и предполагал.
От банальной замены

на

мой 14-килобайтный проект подрос до 66К

Подтягивается некая __cxa_pure_virtual, за ней write и std::terminate().
А уж из std::terminate() - кранты, _Unwind_SjLj_Register, __cxa_begin_catch, __cxa_end_catch и вся остальная кампания, вплоть до RTTI

Сдаётся мне, что это всё-таки баг, ибо флаг -fno-exceptions запрещает исключения.

ЗЫ. Получается, всё же есть возможность создать экземпляр класса с чисто виртуальной функцией?

зато работают исключения (которые нам нах ненужны на контроллерах)

будет время залезу внутрь и посмотрю че происходит по fno-exceptions, во всяком случае после прересборки мои проекы на 600% ужались.


про malloc в эксепшенах мне уже просветили.
как минимум исключение пытаеся дернуть память чтоб сообщение(или контекст исключения) создать которое передается обработчику.

нахер все это нада вырубать.

ктонить объяснит? есть ситуации когда без исключений не написать кода?

Не, исключения - штука в принципе отличная. Но места и памяти - жалко.

Если бы оно (fno-exceptions) всегда работало, всё было бы чудесно. Хочет человек эксепшны - пожалуйста, не хочет - не надо. Но этот pure virtual портит всю малину.

Ну, совсем-то наверное не надо А вот по fno-exceptions - да.

В принципе исключения - это стандарт Си++. Обойтись без них можно, видимо просто в недрах стандартных библиотек они в каком-то месте используются безусловно.

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

я добавил к проекту следующие файлы и с no-exception, no-rtti ничего лишнего не подключается.

malloc и free свои

у меня также, после введения в проекте синонимов malloc free на свои реализации. я писал что -600% по размеру.
остается вопрос - если эксепщены и RTTI выключены то кто malloc free тянет?
я всетаки соберу две версии libctdc++ одну нормально а вторую с no-exception, no-rtti. а там сравним че получится.

О, супер! Хватило только первого файла (sys.c), и всё стало отлично.

2 klen: наверное так и должны выглядеть эти __cxa_xx() при -fno-exceptions. Остальное, судя по всему, в либах правильно.