А вот как определяют, сколько памяти доступно для sbrk/alloc?

Пробрасывать -DSIZE=666 при компиляции.

Ты прям КО. Откуда я вычислю 666?

А может я вообще ни байта не хочу потерять, хочу всю по максимуму использовать память?

Ты не знаешь под какой контролер пишешь/собираешь?

Я не хочу (да и не представляю, как это сделать) вручную считать, сколько у меня используется памяти.

Возможен такой вариант: скомпилять и по карте памяти посмотреть, затем соответствующие изменения внести, и перекомпилять. Но это как-то уж очень костыльно выходит...

Вот, скажем, в том же линуксе поступают "просто": резервируют первые дофига мегабайт памяти (кажись, на современных системах уже сотни!). А мне интересно, как сделать без нерационального использования ресурсов.

как определить, сколько из этого объема займут всякие вспомогательные данные — глобальные переменные, адреса переходов и т.п.?

А откуда может взяться что-то, что не написано в том даташите и чего ты сам не написал? Или ты пишешь под какую-то ОС?

Я не хочу (да и не представляю, как это сделать) вручную считать, сколько у меня используется памяти.

Если речь идёт о простом плоском бинарнике, поставить в конце него метку, взять её адрес и вычесть из неё адрес начала бинарника.

Disclaimer: я не программирую под микроконтроллеры. Имею опыт низкоуровневого программирования для x86.

Я примерно об этом же и писал выше.

А вот интересно: не может ли препроцессор gcc сразу же этот адрес взять, да и вычислить?

Или двойная компиляция (первый раз компиляем только для получения map-файла, из него sed'ом выдираем нужный параметр, объявляем макрос и компиляем второй раз) — не такой уж и велосипед?

Вот так и появляются решения очень многих ЛОРовских тем.

А вот интересно: не может ли препроцессор gcc сразу же этот адрес взять, да и вычислить?

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels-as-Values

поставить в конце него метку, взять её адрес и вычесть из неё адрес начала бинарника

И он получит размер бинарника, но этот размер надо изначально (при компиляции) откуда-то взять, а формируется он с учётом размера _pages[], то есть мы вернулись к первому вопросу :3

Да, блин, оно работает только для меток внутри функции. В этом есть определённая логика.

Тогда можно сделать следующее.

Размер бинарника можно определить после компиляции.

Адрес, куда поместится первый байт бинарника, если не в 0, должен быть известен.

Итак, можно начать бинарник так:

<Перейти на 8 байт вперёд><Размер бинарника - 8 байт><Код>

Тогда, учитывая, что размер инструкции процессора <Перейти на 8 байт вперёд> должен быть заранее известен, можно предсказать адрес, где будет лежать размер бинарника. А сам этот размер записывать туда после компиляции.

Да проще все: gcc создает map-файл (если нужные флаги указать), из которого и берется реальная карта памяти. А второй компиляцией и двигаем соответствующим образом выделенное.

Просто думал, что можно за один проход сделать.

распарсить исполняемый файл по секциям и посчитать размер конечных не константных данных(секции вроде .data) + учесть размер стека?

А второй компиляцией и двигаем соответствующим образом выделенное.

А карта памяти после этого не изменится?

распарсить исполняемый файл по секциям

В исходной задаче ведь ничего не говорилось, что там есть загрузчик ELF или другого нетривиального формата.

Вспоминаются всякие порноархитектуры вроде AVR, в которых код отдельно, а данные отдельно.

Вспоминаются всякие порноархитектуры вроде AVR, в которых код отдельно, а данные отдельно.

Если код отдельно, а данные отдельно, то, очевидно, для данных доступна вся память для данных.

для данных доступна вся память для данных.

Кроме глобальных переменных и стека, что усложняет задачу изобретения malloc.

Кроме глобальных переменных и стека, что усложняет задачу изобретения malloc.

Это вот да, проблема... и как выкручиваются люди?

Скорее всего просто не используют malloc. Тем более это отличный способ ввести утечку памяти.

Изменится, но общий-то объем мы заполним целиком!

freeRTOS использует malloc. Но там, кажись, сильно КПД использования памяти низкий.

Это всё умеет gcc. Я это делал, но давно, по этому забыл как. Но это точно можно сделать. :)

Могу поискать в старых залежах. Делал я как-то ОС с malloc-ом для микроконтроллера.

Вот что нашел.

Файл lpc2148_rom.ld:

ENTRY(_boot)
STACK_SIZE = 0x500;

/* Memory Definitions */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00000000, LENGTH = 512k
  RAM (rw) : ORIGIN = 0x40000000, LENGTH = 32k
}

/* Section Definitions */
SECTIONS
{
  .text :
  {
    src/sys/crt0.o (.text)
    *(.text)
    *(.text.*)
    *(.glue_7)
    *(.glue_7t)
    *(.rodata)
    *(.rodata.*)
  } > ROM

  . = ALIGN(4);
  _etext = . ;

  .data : AT (_etext)
  {
    _data = .;
    *(.data)
  } > RAM
 
  . = ALIGN(4);
  _edata = . ;

  .bss (NOLOAD) :
  {
    __bss_start = . ;
    *(.bss)
    *(COMMON)
  } > RAM

  . = ALIGN(4);
  __bss_end = . ;

  .stack ALIGN(256) :
  {
    . += STACK_SIZE;
    PROVIDE (_stack = .);
  } > RAM

  _end = . ;
  PROVIDE (end = .);
}

А вот из файла mem_alloc.c:

/* Linker provided constant */
extern char end[];

...

heap_start = ((UINT32)end) & 0x00007FFF;

Спасибо. Примерно ясно. В opencm3 есть объявление указателя _stack:

PROVIDE(_stack = ORIGIN(ram) + LENGTH(ram));

Т.е. в принципе, действительно, если с форматом файла линковки разобраться, выходит, что можно все автоматизировать без необходимости многократного запуска gcc.

Для контроллеров и процов у которых нет виртуализации памяти характерна такая особенность кучи как дефрагментация. Поэтому, даже если у вас свободно 4К, но где то по середине кучи выделен 1 байт, то 3К вы не получите, так как непрерывного пространства нет в кучи. Использование кучи в таких системах не безопасно. Используйте пулы памяти. Если требуется определить размер какой либо секции в памяти программ, то это отдельный разговор. Его можно вычислить из определений файла линковщика.

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

Не совсем правильный файл линковщика. Обычно делают так, что бы куча и стек «росли» на встречу друг другу. Т.е. стек в конце памяти, куча сразу с первого свободного байта ОЗУ.

Опять заинтересовался malloc'ами. Вот какую ссылочку нашел:

http://sushihangover.github.io/arm-cortex-m3-bare-metal-with-newlib/

Все нормально реализуется просто через скрипт для линкера! А я долбал бедный люд...