[klen 1]

на этот раз нечто новое.

свежак 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 битных виндах работать не будут. последний нативно под этуже платформу генерит код

[AlexeyVoroshen 0]

Хочу сказать Спасибо 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(.

(оставльные функции пустые)

 

 

 

[AlexeyVoroshen 0]

включаю new (*2):

text data bss dec hex filename

92716 2184 3756 98656 18160 ./SKT7_REC.elf

!!!!!!!!!! 90К текста, 2K data, +2K bss.

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

 

c последним от клёна ~65K текста.

но всё равно, GCC тащит всё, что не надо (unwind, sprint....)

 

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

 

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

 

[klen 1]

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

 

c последним от клёна ~65K текста.

но всё равно, GCC тащит всё, что не надо (unwind, sprint....)

 

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

 

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

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

[AHTOXA 15]

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

-fno-exceptions -fno-rtti

[alx2 0]

включаю malloc (*1):

text data bss dec hex filename

3292 2104 1424 6820 1aa4 ./SKT7_REC.elf

из непонятно откуда появилось 2104 байта data ??????

Попросите линкер сгенерить map-файл - там будет написано, что и почему прилинковано.

но всё равно, GCC тащит всё, что не надо (unwind, sprint....)

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

 

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

 

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

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

[klen 1]

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

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

у меня такая позиция

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

2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.

3. естественно инструмент по задаче нада мерить :)

 

AHTOXA:

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

-fno-exceptions -fno-rtti

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

[AlexeyVoroshen 0]

опции есть:

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 делать :(

[AHTOXA 15]

Добавьте в проект приаттаченный файл по ссылке.

И да, перепишите new/delete, примерно как здесь.

 

[AlexeyVoroshen 0]

Добавьте в проект приаттаченный файл по ссылке.

И да, перепишите new/delete, примерно как здесь.

 

sys.c - у меня похожее уже есть.

Спасибо за совет. Буду пробывать.

 

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

[alx2 0]

1. С++ исключения - это такая хрень которая в маленьких системках является архитектурным маразмом,

2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.

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

 

И да, перепишите new/delete, примерно как здесь.

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

void * operator new(size_t n) throw() { return malloc(n); }

 

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

Изменено 9 сентября, 2010 пользователем alx2

[AHTOXA 15]

В обрамлении вызова malloc() мутексом нет смысла, так как newlib'овский malloc() уже имеет все это внутри. Главное не забыть реализовать __malloc_lock() и __malloc_unlock(), как это и написано в документации.

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

Если нужен всего лишь оператор new, не бросающий исключений, достаточно этого:

void * operator new(size_t n) throw() { return malloc(n); }

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

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

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

[AlexeyVoroshen 0]

Спасибо за помощь.

Буду использовать

>> void * operator new(size_t n) throw() { return malloc(n); }

(расширю под FreeRTOS).

или bget

 

 

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

 

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

[AlexeyVoroshen 0]

Уважаемый 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?

 

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

[klen 1]

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