klen 1 4 сентября, 2010 Опубликовано 4 сентября, 2010 · Жалоба на этот раз нечто новое. свежак 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 7 сентября, 2010 Опубликовано 7 сентября, 2010 · Жалоба Хочу сказать Спасибо 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 7 сентября, 2010 Опубликовано 7 сентября, 2010 · Жалоба включаю 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 7 сентября, 2010 Опубликовано 7 сентября, 2010 · Жалоба ошибочка вышла. 90K со старым yagartoo c последним от клёна ~65K текста. но всё равно, GCC тащит всё, что не надо (unwind, sprint....) для сравнения IAR даёт на похожем примере ~1,5K + 1,5K и где-же грабли закопаны???? грабли тянутся из библиотечного маллока из newlib, нужно переопределить new delete со своим нормальным человеческим аллокатором. unwind я для армов убрал, не должно быть этого кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба И не забыть про ключики -fno-exceptions -fno-rtti Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alx2 0 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба включаю 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 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба По unwind - почему считаете, что не надо? Вы используете оператор new, который может бросить исключение. Насколько я понимаю, unwind используется именно для обработки исключений. ??? Чем плох newlib'овский аллокатор? Использую его много лет в куче разных проектов, с проблемами не сталкивался... у меня такая позиция 1. С++ исключения - это такая хрень которая в маленьких системках является архитектурным маразмом, код целевых алгоритмов будет обычно в разы меньше чем код эксепшенов. можно написать грамотно без эксепшенов сильнее напрягая моск. При мысли сколько чего происходит при вбросе эксешена волосы встают дыбом - это точчно не для маленьких систем :) 2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко. 3. естественно инструмент по задаче нада мерить :) AHTOXA: И не забыть про ключики -fno-exceptions -fno-rtti если используются пользовательские библиотеки тоже должны быть собраны с этими ключами а то линкер до них unwind приятнет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexeyVoroshen 0 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба опции есть: 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 18 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба Добавьте в проект приаттаченный файл по ссылке. И да, перепишите new/delete, примерно как здесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexeyVoroshen 0 8 сентября, 2010 Опубликовано 8 сентября, 2010 · Жалоба Добавьте в проект приаттаченный файл по ссылке. И да, перепишите new/delete, примерно как здесь. sys.c - у меня похожее уже есть. Спасибо за совет. Буду пробывать. P.S. Извините, если посты не в той теме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alx2 0 9 сентября, 2010 Опубликовано 9 сентября, 2010 (изменено) · Жалоба 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 18 9 сентября, 2010 Опубликовано 9 сентября, 2010 · Жалоба В обрамлении вызова 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 10 сентября, 2010 Опубликовано 10 сентября, 2010 · Жалоба Спасибо за помощь. Буду использовать >> void * operator new(size_t n) throw() { return malloc(n); } (расширю под FreeRTOS). или bget а (new(std::nothrow) cll) у меня никоим образом не скомпилировался, как бы я не переписывал. P.S. У меня часто бывают мелкие с-мы, поэтому вопрос и важен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexeyVoroshen 0 20 сентября, 2010 Опубликовано 20 сентября, 2010 · Жалоба Уважаемый 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 21 сентября, 2010 Опубликовано 21 сентября, 2010 · Жалоба Уважаемый 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 из моего пакета. если по какимто причинам собирать не хочется - то правильно так как заработает, но тогда может гденибудь вызезти косяки.. а может и не вылезти. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться