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

Terminator

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

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

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

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

2 515 просмотров профиля
  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. Руками написана конечно же. Задача с конструкторами имеет наивысший приоритет. Если упростить, запуск оси вставлен в стартап перед вызовами конструкторов. Имхо, проблем с библиотеками быть не должно. Хотя опыт использования библиотек у меня никакой.
  4. Вызываются конструкторы куском кода перенесённым из стартапа. Создания объектов избегаю всеми силами. В "богоклассе" вписаны все нужные мне объекты. Конструкторы вызываются в порядке объявления. 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. Попробовал собрать свой загрузчик. Без 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
  8. Вернулся к относительно старому проекту. "свежаками" не собирается. /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".
  9. Согласен, с "проще" я несколько погорячился :) Просто с обычным 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; }
  10. Такой подход требует реализации собственного, аля, сборщика мусора. Почти так и сделал. С std::nothrow сделать не получилось. Сделал проще, operator new(size_t,void*). Кстати, компилятор никаких проверок не вставляет, конструктор вызывается в любом случае. Вставил проверку перед вызовом new.
  11. ну как бы да, можно жёстко ограничить число выделяемых объектов чтобы память 100% не закончилась. А мне хочется и другой вариант попробовать, складывать команды в очередь пока есть свободная память, а потом, те что не влезают, выкидывать. С обычным new это невозможно.
  12. это всё конечно круто, спасибо за код. Но меня тут начали беспокоить внезапные сомнения в применении переопределённого оператора new без исключений. Судя по asm листингам, сразу после вызова оператора new идёт выполнение конструктора, т.е. всё "весело" грохнется если вдруг new вернёт null ... По теории можно применить placement new, сначала выделить память, проверить что её хватило, а потом уже new на эту память. Остаётся вопрос о возможных последствиях выполнения delete на созданный объект. Вероятно всё сработает как надо, вызовется деструктор, а потом память освободится, но везде в примерах пишут явный вызов деструктора и затем явное освобождение памяти.
  13. Попытался на радостях использовать 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. Безнадёга
  14. операторы new и delete переопределены? P. S. да, с lto проект не собирается (Error: offset out of range) :) Собирается только маленькая часть, загрузчик (он по сути является сильно урезанной копией основной прошивки).
×
×
  • Создать...