Coocox настройка heap? Опции

[maxntf]

Не получается настроить кучу в coocox.
По тем пример что на форуме http://www.coocox.org/forum/viewtopic.php?f=2&t=917 у меня не получилось. Во первых потому, что они с ошибками, а во вторых там не указано куда именно в файле *.ld нужна сделать вставку.
В общем я сделал по другому:
1. В файле startup добавил

Код

/*----------Heap Configuration-----------------------------------------------*/
#define HEAP_SIZE       0x00001000
__attribute__ ((section(".heap")))
unsigned long pulHeap[HEAP_SIZE];

2. В файле ld перенес сектор .heap который там уже был, под сектор .co_stack

Код

    /* .stack_dummy section doesn't contains any symbols. It is only
    * used for linker to calculate size of stack sections, and assign
    * values to stack symbols later */
    .co_stack (NOLOAD):
    {
        . = ALIGN(8);
        *(.co_stack .co_stack.*)
    } > ram

    .heap (COPY):
    {
        __end__ = .;
        _end = __end__;
        end = __end__;
        *(.heap*)
        __HeapLimit = .;
    } > ram
    
    /* Set stack top to end of ram , and stack limit move down by
    * size of stack_dummy section */
    __StackTop = ORIGIN(ram ) + LENGTH(ram );
    __StackLimit = __StackTop - SIZEOF(.co_stack);
    PROVIDE(__stack = __StackTop);
    
    /* Check if data + heap + stack exceeds ram  limit */
    ASSERT(__StackLimit >= __HeapLimit, "region ram  overflowed with stack")

В файле syscalls.c вообще ничего не менял.
Вот map файл который получился, и как видно из скриншота, функция calloc возвращает указатель именно из области сектора .heap
Но только не пойму как работает ограничение, когда вылезаем за размеры кучи. Дело в том, что даже если я ставлю HEAP_SIZE 0x00000010. Программа работает но там явно память выделяется за границами кучи.

Сообщение отредактировал maxntf - Apr 16 2016, 15:02

Эскизы прикрепленных изображений

 

[AHTOXA]

Сначала вот вам картинка распределения ОЗУ:

• начало ОЗУ
• переменные
• переменные
• переменные
• сюда вы зачем-то засунули секцию co_stack
• начало кучи
• ↓куча растёт в сторону конца ОЗУ
• ↓куча растёт в сторону конца ОЗУ
• тут пусто
• тут пусто
• тут могут встретиться стек и ОЗУ
• тут пусто
• тут пусто
• ↑сюда растёт стек
• ↑сюда растёт стек
• начало стека (конец ОЗУ)

Теперь пояснения.
секция co_stack, вероятно, фальшивая. То есть, для дела важен только её размер. Вкупе со значением HEAP_SIZE это позволяет линкеру выдать ошибку, если суммарный размер стек+куча+переменные превысит размер ОЗУ. То, что вы поместили эту секцию после секции text и перед секцией .heap, просто оставило неиспользуемый кусок ОЗУ между переменными и кучей.
Размер использованной кучи, скорее всего, не проверяется (можете посмотреть на функцию _sbrk() в syscalls.c. Максимум, что обычно делается - контролируется встреча кучи и стека. (И то далеко не всегда).

[maxntf]

• начало ОЗУ
• переменные
• переменные
• переменные
• сюда вы зачем-то засунули секцию co_stack
• начало кучи
• ↓куча растёт в сторону конца ОЗУ
• ↓куча растёт в сторону конца ОЗУ
• тут пусто
• тут пусто
• тут могут встретиться стек и куча
• тут пусто
• тут пусто
• ↑сюда растёт стек
• ↑сюда растёт стек
• начало стека (конец ОЗУ)

Во первых, огромное спасибо за наглядную картинку - сразу много вещей стало понятно! Редко на форуме понимают тех кто только начинает осваивать новое.

Размер использованной кучи, скорее всего, не проверяется (можете посмотреть на функцию _sbrk() в syscalls.c. Максимум, что обычно делается - контролируется встреча кучи и стека. (И то далеко не всегда).

Из вашего ответа, у меня напрашивается законный вопрос, почему на всех встречающихся примерах всегда указывается размер стека, и кучи?
Честно говоря я думал что стек и куча ограничиваются размером.

P.S.

• сюда вы зачем-то засунули секцию co_stack

Это coocox делает по умолчанию в new_project. и GCC предлагает свой ld с таким расположением.

секция co_stack, вероятно, фальшивая.

Только вспомнил! По адресу 0х08000000 указан адрес 0х200055А8. То есть начало стека, так что получается что стек двигается с этого адреса в конец памяти?

Сообщение отредактировал maxntf - Apr 16 2016, 18:12

[Lmx2315]

Во первых, огромное спасибо за наглядную картинку - сразу много вещей стало понятно!

Только вспомнил! По адресу 0х08000000 указан адрес 0х200055А8. То есть начало стека, так что получается что стек двигается с этого адреса в конец памяти?

..главное похвалить, а саму схему можно не читать.

[maxntf]

..главное похвалить, а саму схему можно не читать.

Да нет, схему я как раз понял. Только в стандартном варианте было примерно так, в понедельник точный map на работе посмотрю и покажу.

Код

.heap                                 0x200055a0     0x0
                                      0x200055a0               __end__ = .
                                      0x200055a0               _end = __end__
                                      0x200055a0               end = __end__
*(.heap*)
.co_stack
                                      0x200055a0     0x2000    ......
                                      0x200055a0               . = ALIGN (0x8)
*(.co_stack .co_stack*)
                                      0x200055a0     0x2000    ......
                                      0x200055a0               __HeapLimit = .
                                      0x20020000               __StackTop = .......
                                      0x2001e000               __StackLimit = .......

Я думал что co_stack это начало стека, и адрес кучи находится там же где и начало стека. По этому и начал пытаться перенести кучу. Точнее вообще понять где она расположена, и как задать ей размер.

P.S.
Я подключил библиотеку декодера speex, и при его инициализации у меня программа улетала в Default_Handler. Скорее всего из за того, что происходило прерывание, обработчик которого я не включил (наверное прерывание по переполнению стека). Программа улетала, когда выполнялась calloc 3-й раз. Я увеличил значение STACK_SIZE и все пошло. Получается что calloc выделяло память из адресного пространства стека (возвращало 0x200055a8), а адрес начала стека все таки 0x200055a0?
Или я все не так понял?

Сообщение отредактировал maxntf - Apr 16 2016, 19:24