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

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

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

ps: sys.c уменьшил или нет код, не присмотрелся 46 килобайт так и осталось (вместо 30 с копейками).
free/malloc, весь stdio и io присутствует, signal, memcpy, syscalls. Я не вызываю ничего из этого.

Сообщение отредактировал Genadi Zawidowski - Feb 3 2010, 20:12

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

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

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

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

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

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

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

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



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

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

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

Что-то у меня не выходит каменный цветок.
avr-gcc.exe - Не удалось найти компонент "Приложению не удалось запуститься, поскольку libiconv-2.dll не был найден"
Я нашёл эту либу в Инете, но получил "Точка входа в процедуру libiconv не найдена в библиотеке DLL libiconv-2.dll"

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

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

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

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

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

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

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

На первый взгляд вполне!Всё бы Вам накатить!:-) НГ праздники прошли, а 8 марта и 23 февраля еще не наступили:-)
Путь они пообсасывают эту тему - мне ничего не мешает пользоваться Gnu'тым ПО и получать, как минимум, моральное удовлетворение.

кому интересен сам процесс.
теперь будет прощще - в результате длительного тупления и лени, которая наконецто пересилила "трудолюбие", написал таки скрипты котрые в результате одной команды с консоли
делают 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.

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

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