2_RabidRabbit

собрал релиз 5.3.0
есть мнение что эта мясорубка прокрутит мясо в фарш даже с костями! пробуйте

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_5.3.0_CARUM.7z

arm-kgp-eabi-g++ (Klen's GNU package (KGP) for x86_64-kgp-linux-gnu platform. << CARUM >>) 5.3.0

кости крутит, а вот будку с цепью не жуёт...

там же недопустимая инструкция и шлёт в bugs.html...

видимо, у меня код какой-то неправильный...

фигня какая-то.
взял binutils-2.25.tar.bz2 gcc-5.3.0.tar.bz2 newlib-2.2.0.tar.gz
кое-как собрал для --target=arm-none-eabi
хотя чё-то там в итоге make install не срослось, но arm-none-eabi-g++ в bin получился
vzaytsev@vzdeb8:~/x64/build/gcc-5.3.0$ arm-none-eabi-g++ --version
arm-none-eabi-g++ (GCC) 5.3.0

и оно собирает мои исходники

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

короче я сам шляпа - дома Atom N2800 и падает, а на работе Core-i3 - и всё зашибизь. Видимо у Вас в бинарники какое-то последнее sse вкралось, которого нет в убогом атоме

в результате меганаведения порядка сделал "MegaPack" свежаков для мелко армов
"по многочисленным просьбам общественности" доделал сборочные скрипты для сборки свежаков под хосты x86_64-kgp-mingw32 и i686-kgp-mingw32
вот оно кучей:

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160228_DICHROMENA.7z
www.klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20160228_DICHROMENA.7z
www.klen.org/Files/DevTools/i686-kgp-mingw32/arm-kgp-eabi_@_i686-kgp-mingw32_20160229_DICHROMENA.7z

а также по пути сборки тулсов хост-хост, может кому понядобится
www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/x86_64-kgp-mingw32_@_x86_64-kgp-linux-gnu_20160228_DICHROMENA.7z
www.klen.org/Files/DevTools/x86_64-kgp-mingw32/x86_64-kgp-mingw32_@_x86_64-kgp-mingw32_20160228_DICHROMENA.7z
www.klen.org/Files/DevTools/i686-kgp-mingw32/i686-kgp-mingw32_@_i686-kgp-mingw32_20160228_DICHROMENA.7z

в связи с возникновением у меня интереса к относительно новым PIC32MZ с FPU наверно сделаю все тоже самое но для MIPS

если в пактах обнаружатся глюки и ли что то нечаянно потерялось - сообщайте, поправлю.
также мне важна обратная связь с пользователями сборок для хостов x86_64-kgp-mingw32 и i686-kgp-mingw32 в связи с тем что я не могу их протестировать.

ну и вообще это все нужно?

LDFLAGS += --specs=nano.specs

получаю на стадии линковки:
ld.exe: cannot find -lc_nano

а как бы все правильно, newlib nano я не собираю, в пакетах у меня всегда newlib.
какоето время назад я пробывал пробывал newlib nano и обнаружил что она практически не отличается от базовой ветки newlib, при этом не оновляется и вообще уже протухла.
есть два варианта
1. забить на --specs=nano.specs, результат скорее всего не изменится
2. самостоятельно собрать newlib-nano как обычную либу

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

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160228_DICHROMENA.7z

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

Попробовал прямо сейчас на текущем проекте:
c nano: 24996 байт
без nano: 35172 байт
ИМХО nano весьма и весьма полезна и вы зря её игнорите(((

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

у всех разные условия - поэтому универсального решения нет.

Что-то на Cortex-M0 вылетает на делении Извиняюсь - думал, что обновил GCC, а он был у меня старый - вроде заработало

Сообщение отредактировал Шаманъ - Mar 5 2016, 21:59

сборочка для MIPS
www.klen.org/Files/DevTools/linux-x86_64/mips-kgp-elf_@_x86_64-kgp-linux-gnu_20160307_DICHROMENA.7z

свежак для мелкоармиков
www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20160329_MELISSA.7z

Приветствую всех!

А это нормально:
D:\.........\Front>arm-kgp-eabi-size -A Debug/Main.elf
Debug/Main.elf :
section size addr
.isr_vector 484 134217728
.text 1168 134218212
.data 4 536870912
.bss 80 536870916
._stack 200 536870996
.comment 104 0
.ARM.attributes 51 0
.debug_aranges 104 0
.debug_info 4984 0
.debug_abbrev 1004 0
.debug_line 741 0
.debug_frame 232 0
.debug_str 2234 0
.debug_loc 238 0
.debug_ranges 144 0
Total 11772

D:\.........\Front>arm-kgp-eabi-size -B Debug/Main.elf
text data bss dec hex filename
1652 4 280 1936 790 Debug/Main.elf

В смысле, что во втором варианте вызова size в bss всчитывается _stack ?