Перейти к содержанию

    

Terminator

Участник
  • Публикаций

    211
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Terminator

  • Звание
    Местный
  • День рождения 18.04.1978

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Томск

Посетители профиля

1 893 просмотра профиля
  • klen

  1. Что-то пошло не так :) Это без lto /opt/arm-kgp-eabi/bin/arm-kgp-eabi-ld.bfd: /tmp/ccXxvaiY.ltrans0.ltrans.o: in function `log10f': /home/LOCALNET/term/Projects/arm/workspace/0xA00_cpu/build/../../../../../../../../src/newlib/newlib/libm/math/wf_log10.c:67: undefined reference to `nan' collect2: error: ld returned 1 exit status
  2. У меня не работает: build $ /opt/arm-kgp-eabi/bin/arm-kgp-eabi-gcc --version Недопустимая инструкция (стек памяти сброшен на диск) Последняя строчка из dmesg: [175140.290577] traps: arm-kgp-eabi-gc[8187] trap invalid opcode ip:4056ea sp:7ffc4ad6a220 error:0 in arm-kgp-eabi-gcc[403000+63000] Host gentoo phenom II X6 P. S. предыдущая версия работает, но проект собрать не может. На этапе линковки вываливает кучу ошибок: /tmp/cc8PlR0G.s: Assembler messages: /tmp/cc8PlR0G.s:15: Error: selected processor does not support ARM opcodes /tmp/cc8PlR0G.s:22: Error: attempt to use an ARM instruction on a Thumb-only processor -- `cmp r2,#0' ... /tmp/cc8PlR0G.s:1441: Error: attempt to use an ARM instruction on a Thumb-only processor -- `b .L548' lto-wrapper: fatal error: /opt/arm-kgp-eabi/bin/arm-kgp-eabi-g++ returned 1 exit status compilation terminated. /opt/arm-kgp-eabi_20170625/bin/../lib/gcc/arm-kgp-eabi/8.0.0/../../../../arm-kgp-eabi/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status И причём здесь lto ? Сборка с lto вылетает с "Error: offset out of range". точно так же как писал ранее.
  3. Цитата(Kabdim @ Feb 16 2018, 21:15) А задача с конструкторами откуда взялась? Руками написана конечно же. Цитата(AHTOXA @ Feb 16 2018, 22:48) Версия с вызовом конструкторов после старта оси мне нравится, но она не подходит для написания библиотек. Библиотечные объекты не могут полагаться на то, что будет использован модифицированный стартап. Задача с конструкторами имеет наивысший приоритет. Если упростить, запуск оси вставлен в стартап перед вызовами конструкторов. Имхо, проблем с библиотеками быть не должно. Хотя опыт использования библиотек у меня никакой.
  4. Цитата(dxp @ Feb 16 2018, 17:43) Это у вас конструкторы глобальных объектов вызываются в какой-то своей функции или вы объекты в ней и создаёте, обеспечивая тем самым гарантированный порядок вызова конструкторов? Вызываются конструкторы куском кода перенесённым из стартапа. Создания объектов избегаю всеми силами. Цитата(Kabdim @ Feb 16 2018, 18:14) Не пойму как вы соединили богоклас и задачу с конструкторами. Не могли бы вы пояснить? В "богоклассе" вписаны все нужные мне объекты. Конструкторы вызываются в порядке объявления. P. S. в качестве ос использую freertos, до scmrtos руки пока не дошли
  5. Я в своих проектах запускаю отдельную задачу которая выполняет все конструкторы. По окончанию задача убивается. Для борьбы с порядком создания, использую god class. Нагородил такое чтобы не париться с вызовами функций ос в конструкторах.
  6. Снова попробовал последний свежак и споткнулся об memset Кодsize_t init_memory_pool(size_t mem_pool_size, void *mem_pool) { /******************************************************************/     tlsf_t *tlsf;     bhdr_t *b, *ib; ...     /* Zeroing the memory pool */     memset(mem_pool, 0, sizeof(tlsf_t)); ругань: Код.../tlsf/tlsf.c:480:5: warning: 'memset' writing 3180 bytes into a region of size 4 overflows the destination [-Wstringop-overflow=]      memset((char*)mem_pool, 0, sizeof(tlsf_t));      ^ /tmp/ccutHzBY.s: Assembler messages: /tmp/ccutHzBY.s:3170: Error: offset out of range lto-wrapper: fatal error: /opt/arm-kgp-eabi/bin/arm-kgp-eabi-g++ returned 1 exit status mem_pool "достаётся" здесь: Код    unsigned long* p = &__heap_start__;     *p = 0;     unsigned long* e = &__heap_end__;     unsigned long len = (char*) e - (char*) p;     pool = p;     init_memory_pool(len, pool); __heap_start__ и __heap_end__ из .ld Без lto собирается, но не влезает. P. S. на такой же memset вставленный перед вызовом init_memory_pool, не ругается.
  7. Цитата(Шаманъ @ Apr 27 2017, 20:44) Разобрался, собрал. С lto cборка ZINGIBER медленнее почти в 3 раза... Как разобрался?
  8. Цитата(klen @ Jan 9 2017, 03:44) сборка из релизного кода 6.3.0 www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_6.3.0_BOTRYCHIUM.7z Попробовал собрать свой загрузчик. Без lto собирает, но не влазит (и результат заметно толще чем от "свежака" 20151209), а с lto не хочет: Код/tmp/ccnVfbCz.ltrans2.ltrans.o: In function `realloc': <artificial>:(.text+0xcae): undefined reference to `memcpy' /tmp/ccnVfbCz.ltrans2.ltrans.o: In function `prvCopyDataFromQueue.lto_priv.178': <artificial>:(.text+0x548): undefined reference to `memcpy' /tmp/ccnVfbCz.ltrans4.ltrans.o: In function `ResetISR': <artificial>:(.isr_vector.ResetISR+0xea): undefined reference to `memset' /tmp/ccnVfbCz.ltrans3.ltrans.o: In function `prvCopyDataToQueue.constprop.106': <artificial>:(.text+0x88): undefined reference to `memcpy' /tmp/ccnVfbCz.ltrans3.ltrans.o: In function `Lpc1768FlashUpdate::FrmCompare(unsigned int, void*, unsigned int)': <artificial>:(.text+0x1e0): undefined reference to `memcmp' /tmp/ccnVfbCz.ltrans6.ltrans.o: In function `MemoryUpdate::FrmCompare(unsigned int, void*, unsigned int)': <artificial>:(.text+0x164): undefined reference to `memcmp' /opt/arm-kgp-linux-6.3.0/bin/../lib/gcc/arm-kgp-eabi/6.3.0/thumb/cortex-m3/libgcc.a(_aeabi_uldivmod.o): In function `__aeabi_uldivmod': (.text+0x20): undefined reference to `__udivmoddi4' collect2: error: ld returned 1 exit status
  9. Вернулся к относительно старому проекту. "свежаками" не собирается. Код/tmp/ccby68ut.s: Assembler messages: /tmp/ccby68ut.s:3065: Error: offset out of range lto-wrapper: fatal error: /opt/arm-kgp-eabi/bin/arm-kgp-eabi-g++ returned 1 exit status compilation terminated. /opt/arm-kgp-eabi_20161204/bin/../lib/gcc/arm-kgp-eabi/7.0.0/../../../../arm-kgp-eabi/bin/ld: error: lto-wrapper failed Это загрузчик, без lto не влезал в заданный размер. Раньше собирался каким-то из вариантов bleeding-edge. "Отматывал" скачанные "свежаки", собрался только "<< HYPERICUM >> 6.0.0 20151208".
  10. Цитата(Сергей Борщ @ Sep 10 2016, 14:09) Проще? Покажите, сравним. Это так по-русски - чуть что, придумывать свой велосипед. Причем почти всегда с квадратными колесами. Согласен, с "проще" я несколько погорячился Просто с обычным new(std::nothrow) у меня проект не собирается, зачем-то тащит библиотечную "кучу" и что-то про исключения. Вот мой код. Код                 void* __mem = malloc(sizeof(Packet)); if (__mem == nullptr) {         ... } else {     packet = new(__mem) Packet(...);         ... переопределение new Кодvoid* operator new(size_t size, void* p) {     (void) size;     return p; }
  11. Цитата(Сергей Борщ @ Sep 9 2016, 14:57) У меня в таком случае в перегруженном operator new() из очереди удаляются самые старые события (которые, наверняка, уже мало кому интересны) и после каждого удаления производится повторная попытка выделить память для нового события. Если очередь уже пуста, а памяти все еще не хватает - то, значит, что-то уже сильно порушено и остается только перезагружаться. Такой подход требует реализации собственного, аля, сборщика мусора. Цитата(Сергей Борщ @ Sep 9 2016, 14:57) А с operator new ( std::size_t count, const std::nothrow_t& tag) - возможно. В этом случае компилятор вставляет проверку возвращенного new(std::nothrow) указателя и вызывает конструктор только в том случае, если new вернул не 0. Почти так и сделал. С std::nothrow сделать не получилось. Сделал проще, operator new(size_t,void*). Кстати, компилятор никаких проверок не вставляет, конструктор вызывается в любом случае. Вставил проверку перед вызовом new.
  12. ну как бы да, можно жёстко ограничить число выделяемых объектов чтобы память 100% не закончилась. А мне хочется и другой вариант попробовать, складывать команды в очередь пока есть свободная память, а потом, те что не влезают, выкидывать. С обычным new это невозможно.
  13. Цитата(klen @ Sep 6 2016, 17:41) ... это всё конечно круто, спасибо за код. Но меня тут начали беспокоить внезапные сомнения в применении переопределённого оператора new без исключений. Судя по asm листингам, сразу после вызова оператора new идёт выполнение конструктора, т.е. всё "весело" грохнется если вдруг new вернёт null ... По теории можно применить placement new, сначала выделить память, проверить что её хватило, а потом уже new на эту память. Остаётся вопрос о возможных последствиях выполнения delete на созданный объект. Вероятно всё сработает как надо, вызовется деструктор, а потом память освободится, но везде в примерах пишут явный вызов деструктора и затем явное освобождение памяти.
  14. Попытался на радостях использовать std::vector ... Код/opt/arm-kgp-eabi/lib/gcc/arm-kgp-eabi/7.0.0/include/c++/bits/stl_algobase.h: In instantiation of 'void std::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = long unsigned int*; _Tp = int]': /opt/arm-kgp-eabi/lib/gcc/arm-kgp-eabi/7.0.0/include/c++/bits/stl_bvector.h:402:55:   required from here /opt/arm-kgp-eabi/lib/gcc/arm-kgp-eabi/7.0.0/include/c++/bits/stl_algobase.h:729:37: error: '__glibcxx_requires_valid_range' was not declared in this scope        __glibcxx_requires_valid_range(__first, __last);        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ compilation terminated due to -Wfatal-errors. Безнадёга
  15. Цитата(klen @ Sep 2 2016, 16:52) сам использую фичи С++14 и все делал для того чтоб никаких "ушей и хвостов от больших машин" не прилазили в код операторы new и delete переопределены? P. S. да, с lto проект не собирается (Error: offset out of range) Собирается только маленькая часть, загрузчик (он по сути является сильно урезанной копией основной прошивки).