[AHTOXA 18]

sys.zip - это заплата, спсибо, но я не стал бы её использовать. Я не хотел бы терять контроля над кодом, дабы избежать непредсказуемого поведения в embedded приложении.

 

А в чём состоит контроль над кодом? Тем более, если он всё равно весь вылетает в discard? :)

 

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

[GenaSPB 11]

если в discard ушло что-то нужное, на что есть ссылки в остальном коде, получаем сообщение об ошибке. Так, весь код попавший в discard, все ссылки имел только внутри себя (примерно так, на абсолютную точность в логике и совершенное знание как транслируется сейчас код gcc для arm не претеную). Есть ещё экзотика типа обращение между адресами определёнными в скрипте линкера или стартапе, но на такое багогенерирующее усовершенствование ответственные програмисты идут неохотно.

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

 

ps: sys.c уменьшил или нет код, не присмотрелся 46 килобайт так и осталось (вместо 30 с копейками).

free/malloc, весь stdio и io присутствует, signal, memcpy, syscalls. Я не вызываю ничего из этого.

Изменено 3 февраля, 2010 пользователем Genadi Zawidowski

[AHTOXA 18]

ps: sys.c уменьшил или нет код, не присмотрелся 46 килобайт так и осталось (вместо 30 с копейками).

free/malloc, весь stdio и io присутствует, signal, memcpy, syscalls. Я не вызываю ничего из этого.

 

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

 

2 klen, может ключик --disable-libunwind-exceptions при конфигурировании нас спасёт?

[GenaSPB 11]

библотека-то одна на всё. Просто выдачу сообщения в обработчике надо как-то перехватить. Или делать разные библиотеки.

[klen 1]

можно собрать без обработки С++ эксепшенов.

а можно эту хрень в DISCARD

 

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

 

както этот вопрос обсуждался сдесь на форуме - тема С++ была, разобрались, пришли к какомуто продуктивному выводу (в том числе и по сборке gcc), помню что пришлоть мучится с тем чтоб конструкторы заработали и еще чето там,

после этого всем стало хорошо и я уже забыл суть :( помойму на эксепшены былы уложены под большой каток

нада поиском порытся.

[AHTOXA 18]

можно собрать без обработки С++ эксепшенов.

 

Эксепшены - это не обязательно C++. Вон, у Genadi Zawidowski - чисто Си, и на тебе, эксепшены. Причём я так и не понял, откуда они прицепились. Судя по map, из какого-то банального __aeabi_uldivmod.

 

Кстати, arm-kgp-elf- от сентября прошлого года даёт на его проекте 31К вместо 47 нынешних. Сдаётся мне, что что-то всё же не так собралось:)

 

както этот вопрос обсуждался сдесь на форуме - тема С++ была, разобрались, пришли к какомуто продуктивному выводу (в том числе и по сборке gcc), помню что пришлоть мучится с тем чтоб конструкторы заработали и еще чето там,

после этого всем стало хорошо и я уже забыл суть :( помойму на эксепшены былы уложены под большой каток

 

Ну так это как раз у меня конструкторы и не работали:) Потом заработали, да. А с эксепшенами тогда ничего не решили, Terminator предложил заглушки, и на этом всё благополучно затихло.

 

Вот, кстати цитата оттуда:

я всетаки соберу две версии libctdc++ одну нормально а вторую с no-exception, no-rtti. а там сравним че получится.

 

:rolleyes:

[klen 1]

Эксепшены - это не обязательно C++. Вон, у Genadi Zawidowski - чисто Си, и на тебе, эксепшены. Причём я так и не понял, откуда они прицепились. Судя по map, из какого-то банального __aeabi_uldivmod.

 

Кстати, arm-kgp-elf- от сентября прошлого года даёт на его проекте 31К вместо 47 нынешних. Сдаётся мне, что что-то всё же не так собралось:)

 

 

 

Ну так это как раз у меня конструкторы и не работали:) Потом заработали, да. А с эксепшенами тогда ничего не решили, Terminator предложил заглушки, и на этом всё благополучно затихло.

 

Вот, кстати цитата оттуда:

 

 

:rolleyes:

 

ну теперь отглохнет, и точно пересоберем и посмотрим че выйдет.

[demiurg_spb 0]

свежак для avr

www.klen.org/Files/DevTools/kgp_avr_20091202_i686-pc-mingw32.7z

Что-то у меня не выходит каменный цветок.

avr-gcc.exe - Не удалось найти компонент "Приложению не удалось запуститься, поскольку libiconv-2.dll не был найден"

Я нашёл эту либу в Инете, но получил "Точка входа в процедуру libiconv не найдена в библиотеке DLL libiconv-2.dll"

 

Вас не затруднит написать пару строк по инсталляции Ваших сборок на "чистый" компьютер. Спасибо!

[klen 1]

Что-то у меня не выходит каменный цветок.

avr-gcc.exe - Не удалось найти компонент "Приложению не удалось запуститься, поскольку libiconv-2.dll не был найден"

Я нашёл эту либу в Инете, но получил "Точка входа в процедуру libiconv не найдена в библиотеке DLL libiconv-2.dll"

 

Вас не затруднит написать пару строк по инсталляции Ваших сборок на "чистый" компьютер. Спасибо!

 

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

ibiconv-2.dll и вообще все дллки нужны моей сборки - я их собираю из свежих исходников, поэтому интерфейс функций может менятся, на что вы собственно и напоролись

 

вот либы, в следущей сборке все должно быть уже без этого гемора.

bin.7z

[demiurg_spb 0]

Спасибо! Заработало.

 -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -ffunction-sections -fdata-sections -fno-tree-scev-cprop -fno-move-loop-invariants  -std=c99

gcc-4.3.2(WinAVR)    65362 bytes    30 sec
gcc-4.3.3(WinAVR)    65066 bytes    35 sec
gcc-4.5.0(Klen)      64552 bytes    58 sec

А что так медленно?

[klen 1]

Спасибо! Заработало.

 -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -ffunction-sections -fdata-sections -fno-tree-scev-cprop -fno-move-loop-invariants  -std=c99

gcc-4.3.2(WinAVR)    65362 bytes    30 sec
gcc-4.3.3(WinAVR)    65066 bytes    35 sec
gcc-4.5.0(Klen)      64552 bytes    58 sec

А что так медленно?

а хрен его знает.

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

 

Но сгенеренный код то хоть устраивает или я зря каллории трачу?

В соседней теме накат на открытый софт пошел такой что.... даже не знаю, отобъемся или в асфаль закатают :smile3009:

[demiurg_spb 0]

Но сгенеренный код то хоть устраивает или я зря каллории трачу?

На первый взгляд вполне!

В соседней теме накат на открытый софт пошел такой что.... даже не знаю, отобъемся или в асфаль закатают :smile3009:

Всё бы Вам накатить!:-) :cheers: НГ праздники прошли, а 8 марта и 23 февраля еще не наступили:-)

Путь они пообсасывают эту тему - мне ничего не мешает пользоваться Gnu'тым ПО и получать, как минимум, моральное удовлетворение.

[klen 1]

кому интересен сам процесс.

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

делают update всех исходников тулсов, либ, ...

собирают по цепочке тулсы под linux-x64 для таргетов linux-x64 i686-pc-mingw32 avr arm mips

они собирают ихже но для хоста i686-pc-mingw32

пакуется в дистрибутивы. на этом заканчивается сборка KGP СВЕЖАКА. а я это время лежал на диване например.

 

итак. дошли руки до авыэрок.

все свежее сегодняшнее(исходники)

для того что собрать avr-libc из репозитория пришлось добавить поддержку девайсов binutils gcc:

attiny2313a

attiny24a

attiny25

attiny44a

attiny4312

attiny261a

attiny461a

attiny861a

attmega644pa

attmega48pa

attmega48a

attmega88a

attmega88pa

attmega16a

attmega164a

attmega165a

attmega168a

attmega169a

attmega169pa

attmega16hva2

attmega324a

attmega324pa

attmega238

attmega329pa

attmega644a

attmega645a

attmega645p

attmega64hve

attmega6450

attmega6490a

attmega5490p

attmega649a

attmega649p

 

архив www.klen.org/Files/DevTools/kgp_avr_20100208_i686-pc-mingw32.7z

 

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

если оно все нормально будет компилировать, добавлю измеения исходников в GCC trunk.

[demiurg_spb 0]

архив www.klen.org/Files/DevTools/kgp_avr_20100208_i686-pc-mingw32.7z

Спасибо!

Вы видимо собрали с новой версией msys-1.0.dll? Некоторые тулзы из WinAVR/utils/bin (например gawk) стали вываливаться с матами на стек.

Наверное надо свежий комплект утилей от msys качнуть.

[klen 1]

2_demiurg_spb

msys-1.0.dll для компиллера не нужна. ее требуют sh make rm котрые я не собираю (но могу ) я их добавляю чтоб можно было без установки msys+mingw получить минимальный набор средств конандной строки для работы

если не хотите менть утилиты MSYSa на новые, грохните в моем дистрибутиве msys-1.0.dll sh.exe make.exe rm.exe и используйте установленне ранее. компиллеру эта хрень не нужна.