на этот раз нечто новое.
свежак GCC для хоста - масдай x86_64, я проверил на Win7 64bit, на висте 64 не пробывал.

для arm
http://klen.org/Files/DevTools/kgp-arm-eab..._64_20100904.7z

для mingw64
http://klen.org/Files/DevTools/kgp-x86_86-...w32_20100904.7z

!!! эти пакеты скомпилены для x86_64, на 32 битных виндах работать не будут. последний нативно под этуже платформу генерит код

Хочу сказать Спасибо klen-у.
Свежие сборки очень хороши.

И задать уважаемому all вопрос по ARM GCC C++
Может, кто нибудь знает, как бороться с malloc и new?
беда такая: достался мне в наследство проект под AT91SAM7A3, написан на С++ и использует new.
(IAR 4.30) ~30K flash.
Решил перевести его на лицензионный GCC от Klen-а

Тестовая прожка:

#include <malloc.h>
class cll { int sss; };
cll* c1;
void* xxx = 0;

int main( void ) {
xxx = malloc( 8 ); *1
c1 = new cll; *2
}

чистый main (без *1 и *2):
text data bss dec hex filename
492 0 1368 1860 744 ./SKT7_REC.elf
всё нормально - стеки, кучи дают 1368 bss.

включаю malloc (*1):
text data bss dec hex filename
3292 2104 1424 6820 1aa4 ./SKT7_REC.elf
из непонятно откуда появилось 2104 байта data ??????, text терпимо

включаю new (*2):
text data bss dec hex filename
92716 2184 3756 98656 18160 ./SKT7_REC.elf
!!!!!!!!!! 90К текста, 2K data, +2K bss.

это при том, что IAR давал на полном проекте 30К text + 30К bss, где десятки new, FreeRTOS и др.

Посоветуйте пожалуйста, что с этим делать!!!

P.S. Конечно есть syscalls.c, и функция void * _sbrk_r(.
(оставльные функции пустые)

ошибочка вышла. 90K со старым yagartoo

c последним от клёна ~65K текста.
но всё равно, GCC тащит всё, что не надо (unwind, sprint....)

для сравнения IAR даёт на похожем примере ~1,5K + 1,5K

и где-же грабли закопаны????

грабли тянутся из библиотечного маллока из newlib, нужно переопределить new delete со своим нормальным человеческим аллокатором. unwind я для армов убрал, не должно быть этого кода.

И не забыть про ключики
-fno-exceptions -fno-rtti

Попросите линкер сгенерить map-файл - там будет написано, что и почему прилинковано.
Тащит не GCC, а линкер. Линкер работает очень просто - он загружает секцию из библиотеки если имеются ссылки на определенные в ней символы. Ненужное он не тянет. Если Вы считаете, что какая-то из загруженных линкером секций не должна быть прилинкована, смотрите map-файл. Там будет написано, для разрешения какого символа была прилинкована эта секция, и где ссылка на этот символ встретилась. После этого разбирайтесь, почему там ссылаются на не нужный по вашему мнению код. В данном примере sprintf действительно линковаться не должен. Смотрите в map-файле, кто на него сослался.

По unwind - почему считаете, что не надо? Вы используете оператор new, который может бросить исключение. Насколько я понимаю, unwind используется именно для обработки исключений.

??? Чем плох newlib'овский аллокатор? Использую его много лет в куче разных проектов, с проблемами не сталкивался...

у меня такая позиция
1. С++ исключения - это такая хрень которая в маленьких системках является архитектурным маразмом, код целевых алгоритмов будет обычно в разы меньше чем код эксепшенов. можно написать грамотно без эксепшенов сильнее напрягая моск. При мысли сколько чего происходит при вбросе эксешена волосы встают дыбом - это точчно не для маленьких систем
2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.
3. естественно инструмент по задаче нада мерить

AHTOXA:
И не забыть про ключики
-fno-exceptions -fno-rtti
если используются пользовательские библиотеки тоже должны быть собраны с этими ключами а то линкер до них unwind приятнет.

опции есть:
CPPFLAGS_LIST = -fno-exceptions -fno-rtti -Wa,-adhlns=$(OUTDIR)/$(<F:.cpp=.lst)
но из библиотеки тянется много всего:

c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o)
main.o (operator new(unsigned int))
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o) (__gxx_personality_v0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_catch.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__cxa_begin_catch)
..........................

и даже unwind
...
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__aeabi_unwind_cpp_pr0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(libunwind.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o) (restore_core_regs)
...
и т.д.

версия: kgp_arm_eabi_20100802.7z

т.е. боюсь придётся свой new/delete делать

Добавьте в проект приаттаченный файл по ссылке.
И да, перепишите new/delete, примерно как здесь.

sys.c - у меня похожее уже есть.
Спасибо за совет. Буду пробывать.

P.S. Извините, если посты не в той теме.

Бесспорно. Но у Алексея система на ARM процессоре, и я поэтому предположил, что памяти в системе достаточное количество, чтобы не дрожать над каждым "лишним" килобайтом...

В обрамлении вызова malloc() мутексом нет смысла, так как newlib'овский malloc() уже имеет все это внутри. Главное не забыть реализовать __malloc_lock() и __malloc_unlock(), как это и написано в документации. Если нужен всего лишь оператор new, не бросающий исключений, достаточно этого:
void * operator new(size_t n) throw() { return malloc(n); }

А что, вызов стандартного оператора new без исключений (new(std::nothrow) cll) не помогает?

Сообщение отредактировал alx2 - Sep 9 2010, 05:57

Это решение получается мало того, что компиляторозависимым, так ещё и зависимым от реализации malloc(). А в случае явного прописывания мутекса - универсальным. Я, например, использую с этим кодом bget.

Если устраивает стандартный malloc(), то да.

Так неудобно же!

Спасибо за помощь.
Буду использовать
>> void * operator new(size_t n) throw() { return malloc(n); }
(расширю под FreeRTOS).
или bget


а (new(std::nothrow) cll) у меня никоим образом не скомпилировался, как бы я не переписывал.

P.S. У меня часто бывают мелкие с-мы, поэтому вопрос и важен.

Уважаемый Klen, ответьте пожалуйста на вопрос по поводу сборки kgp_arm_eabi_20100802:

Ваша сборка использует libstdc++-6.dll с размером 712718байт.
эта версия конфликтует с DLL от Qt (4.6.x) с размером 812032байта.

Я нашёл 1 решение: перенести libstdc++-6.dll с размером 712718байт в каталог
kgp_arm_eabi\libexec\gcc\arm-kgp-eabi\4.6.0\
всё заработало (и kgp_arm_eabi_20100802 и Qt).

Правильно ли я сделал? необходимо ли использовать DLL в Ваших сборках или вы можете собирать сборки без DLL?

Заранее Спасибо.

правильно - это моей сборкой собрать QT из исходников. тогда Qt будект слинкована и грузить libstdc++-6.dll из моего пакета. если по какимто причинам собирать не хочется - то правильно так как заработает, но тогда может гденибудь вызезти косяки.. а может и не вылезти.