Скрипт компоновщика GNU ld для микроконтроллеров

Как компоновщик собирает программу

Каждый файл исходного текста компилятор превращает в объектный файл с набором секций. Код функций ложится в .text, константы и строки — в .rodata, переменные с ненулевым начальным значением — в .data, переменные без начального значения или с нулевым — в .bss. С ключами -ffunction-sections и -fdata-sections каждая функция и каждая переменная получают собственную секцию, названную по их имени, например .text.main или .bss.counter. Это позволяет ключу компоновщика --gc-sections выбросить неиспользуемые функции поштучно: он оставляет секцию с точкой входа и рекурсивно всё, на что есть ссылки, а остальное удаляет.

Компоновщик читает скрипт, собирает выходные секции, раскладывает их по областям памяти подряд, вычисляет значения символов, подставляет адреса в команды и пишет файл ELF. Как устроен ELF и что из него попадает в HEX и BIN, разобрано в статье о файлах прошивки.

Откуда берётся скрипт:

• STM32 и другие Cortex-M. Скрипт — файл проекта, ключ GCC -T script.ld передаёт его компоновщику. Документация GCC отмечает, что для «голых» платформ без операционной системы -T бывает обязателен. Скрипт из -T заменяет стандартный, а не дополняет его, поэтому в нём должно быть описано всё.
• AVR. avr-gcc по ключу -mmcu выбирает эмуляцию компоновщика, для ATmega328P это avr5, и ld использует встроенный скрипт, собранный из шаблона scripttempl/avr.sc и параметров emulparams/avr5.sh. Ключ --verbose заставляет ld напечатать скрипт, которым он пользуется: avr-gcc -mmcu=atmega328p … -Wl,--verbose.

В скрипте три вида содержимого: описание памяти (MEMORY), правила размещения секций (SECTIONS) и команды с присваиваниями символов: ENTRY, PROVIDE, ASSERT и выражения вида _estack = …;.

MEMORY: области памяти

Команда MEMORY перечисляет области памяти. Так она выглядит в шаблоне ST для STM32F103xB (выдержка из STM32F103XB_FLASH.ld):

MEMORY
{
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
}

ORIGIN — начальный адрес, LENGTH — размер в байтах; суффиксы K и M умножают число на 1024 и 1024 × 1024. Имена областей существуют только внутри скрипта и с именами символов и секций не пересекаются. Значения подставляются в выражения функциями ORIGIN(RAM) и LENGTH(RAM).

В скобках после имени — атрибуты:

С атрибутами связано частое заблуждение. Они не делают область доступной только на чтение и ничего не запрещают. Компоновщик использует их, чтобы выбрать область для выходной секции, у которой не указаны ни адрес, ни область >REGION: он берёт первую область с подходящими атрибутами. Сюда относятся и «сироты» — входные секции, не упомянутые ни в одном правиле SECTIONS, для которых компоновщик сам создаёт выходную секцию с тем же именем. Запись RW!X подходит секции для чтения или записи, но только если она не исполняемая. Для секций, направленных в область явно (>FLASH), атрибуты не проверяются.

Область нужна компоновщику для двух вещей. Он ставит очередную секцию на следующий свободный адрес области и проверяет, что секции в неё помещаются; переставлять секции, чтобы они влезли, компоновщик не будет. Если не помещаются — сборка заканчивается ошибкой. Только эта проверка и связывает скрипт с реальным микроконтроллером: если LENGTH больше настоящей памяти, программа соберётся и сломается уже на плате.

SECTIONS: входные и выходные секции

Правило SECTIONS описывает выходную секцию: имя, список входных секций и область памяти. Общий вид:

SECTIONS
{
  .output_name :
  {
    *(.input_name)          /* input sections from all files */
    *(.input_name*)         /* .input_name and .input_name.anything */
    symbol = .;             /* a symbol gets the current address */
  } >VMA_REGION AT>LMA_REGION
}

Что важно знать о шаблонах входных секций:

• *(.text) — секции .text из всех входных файлов; *(.text*) — ещё и .text.main, .text.Reset_Handler и прочие, которые дают -ffunction-sections.
• *(.text .rodata) перемешивает секции в порядке входных файлов, а *(.text) *(.rodata) кладёт сначала все .text, потом все .rodata.
• Вместо * можно указать файл: data.o(.data); а EXCLUDE_FILE исключает файлы из шаблона.
• COMMON — так называемые общие символы, неинициализированные глобальные переменные старого стиля; их кладут в .bss: *(.bss) *(COMMON).
• Если входная секция подходит под несколько правил, она достаётся первому из них по тексту скрипта.

Счётчик адреса «.»

Точка — счётчик адреса, текущее место размещения. symbol = .; создаёт символ со значением текущего адреса, . = ALIGN(4); выравнивает счётчик вверх до кратного 4, . = . + 0x400; оставляет дыру в 1 КБ. Назад внутри выходной секции счётчик двигать нельзя. Есть тонкость: внутри описания секции «.» — смещение от её начала, а не абсолютный адрес, так что . = 0x200 внутри .text означает «секция длиной 0x200 байт», а не «перейти на адрес 0x200».

Символы скрипта в программе на C

Символ, определённый в скрипте, — это адрес без значения: компоновщик создаёт запись в таблице символов, но память под переменную не выделяет. Поэтому в C его объявляют внешним объектом и берут адрес, а не значение:

extern uint32_t _sdata, _edata;            /* defined in the linker script */

size_t data_size(void)
{
    return (size_t)((uintptr_t)&_edata - (uintptr_t)&_sdata);   /* &symbol, never symbol */
}

Второй способ — объявить символ массивом: extern char _sdata[];, тогда имя само даёт адрес. Обращение _sdata без & прочитает слово по адресу начала .data, то есть значение первой переменной, — частая ошибка.

PROVIDE, KEEP, ENTRY, /DISCARD/ и ASSERT

• PROVIDE(symbol = …) определяет символ, только если на него ссылаются и он не определён в программе. Если программа определит символ сама, используется её определение, без ошибки о повторном определении. PROVIDE_HIDDEN делает то же, но символ получает скрытую видимость ELF и не экспортируется из выходного файла; для прошивки разницы нет.
• KEEP(*(.isr_vector)) не даёт --gc-sections удалить секцию. Компоновщик оставляет то, до чего можно дойти по ссылкам от точки входа, а на таблицу векторов не ссылается ни одна функция: её читает ядро. То же касается .init_array и .fini_array со списками конструкторов.
• ENTRY(Reset_Handler) задаёт точку входа ELF. Микроконтроллер её не читает — после сброса он берёт адрес из таблицы векторов, — но она нужна отладчику и служит корнем для сборки мусора.
• /DISCARD/ — специальная выходная секция: всё, что в неё попало, в файл не записывается.
• ASSERT(выражение, "сообщение") останавливает компоновку с сообщением, если выражение равно нулю. В стандартном скрипте AVR так проверяется, что .progmem не выходит за первые 64 КБ.

VMA и LMA: где секция живёт и где хранится

У каждой секции два адреса: VMA — где она находится во время работы, и LMA — куда её записывают при прошивке. Для кода и констант они совпадают, для .data — нет: переменные работают в ОЗУ, а начальные значения должны пережить отключение питания и хранятся во флеш-памяти. В скрипте это записывается так:

• >RAM задаёт область для VMA;
• AT>FLASH задаёт область для LMA: секция получит следующий свободный адрес во флеш-памяти;
• AT(выражение) задаёт LMA конкретным адресом;
• функция LOADADDR(.data) возвращает LMA секции, по ней код запуска узнаёт, откуда копировать.

Если ни AT, ни AT> нет, компоновщик выбирает LMA сам: при явно заданном VMA берёт LMA равным ему, иначе сохраняет ту же разницу VMA − LMA, что у предыдущей секции в той же области. Счётчик «.» всегда считает VMA. Подробно о том, как два адреса хранятся в ELF и почему ошибка с LMA раздувает BIN-файл до сотен мегабайт, — в статье о файлах прошивки.

Разбор шаблона ST для STM32F103

Для разбора возьмём шаблон STM32F103XB_FLASH.ld из репозитория STMicroelectronics cmsis-device-f1 (коммит c8e9a4a от 21 марта 2025 года): он рассчитан на STM32F103xB со 128 КБ флеш-памяти и 20 КБ ОЗУ. В заголовке файла указаны авторские права Ac6 и запрет распространять файл, поэтому ниже — описание и короткие выдержки, а не текст целиком. По порядку сверху вниз:

Пара замечаний к таблице. Правило /DISCARD/ стоит после всех правил размещения, а входная секция достаётся первому подходящему правилу, поэтому код и данные библиотек, уже размещённые выше, оно не трогает. Выравнивание . = ALIGN(4) вокруг _sdata, _edata и _ebss нужно потому, что код запуска копирует и обнуляет память словами по 4 байта.

Код запуска и символы скрипта

Стартовый файл startup_stm32f103xb.s из того же репозитория в обработчике сброса по порядку вызывает SystemInit, копирует словами начальные значения из _sidata в область от _sdata до _edata, записывает нули от _sbss до _ebss, вызывает __libc_init_array (функции из .init_array) и затем main. Таблица векторов g_pfnVectors лежит в секции .isr_vector: слово 0 — _estack, слово 1 — Reset_Handler, дальше адреса обработчиков; у STM32F103xB это 67 слов, 0x10C байт. Символы стартовый файл не определяет, а берёт из скрипта, поэтому их имена должны совпадать — undefined reference to `_sidata' означает, что скрипт и стартовый файл взяты из разных комплектов.

Почему _estack = 0x20004FFF — плохая идея

ОЗУ STM32F103xB занимает адреса от 0x20000000 до 0x20004FFF, и _estack = 0x20004FFF выглядит как «последний байт ОЗУ». Но стек Cortex-M полный нисходящий: SP указывает на последний сохранённый элемент, и перед записью он сначала уменьшается. Поэтому правильная вершина — адрес на единицу больше последнего байта, 0x20005000: первое слово ляжет в 0x20004FFC.

Что происходит с 0x20004FFF: при сбросе ядро читает слово 0 таблицы векторов и обнуляет у него два младших бита (псевдокод сброса в ARMv7-M ARM, разд. B1.5.5). MSP получает 0x20004FFC, верхние 4 байта ОЗУ пропадают, а SP кратен 4, но не 8. Стандарт вызовов AAPCS требует, чтобы на входе в функцию SP был кратен 8 (ARMv7-M ARM, разд. B1.5.7; AAPCS32, «Stack constraints at a public interface»), а обработчик сброса стартового файла SP заново не устанавливает, так что уже SystemInit и main вызываются с нарушенным выравниванием. Сломаться может то, что рассчитывает на выравнивание 8: double и uint64_t в стеке и особенно функции с переменным числом аргументов. По AAPCS32 объект с выравниванием 8 в списке аргументов лежит по адресу, кратному 8, и va_arg в printf на это полагается, поэтому характерный симптом — мусор вместо числа в printf("%f", x). В шаблоне для платы Nucleo из пакета STM32CubeF1 (SW4STM32) стоит правильное 0x20005000. Надёжнее не писать число руками, а вычислить его от описания памяти:

_estack = ORIGIN(RAM) + LENGTH(RAM);    /* one past the last RAM byte */

У STM32F1 есть и второй источник того же сбоя. В его ядре Cortex-M3 ревизии r1p1 бит STKALIGN регистра CCR после сброса равен 0 (в r2p0 значение по умолчанию сменили на 1 — TRM Cortex-M3 r2p1, разд. 1.6.3), и при входе в прерывание ядро выравнивает кадр только на 4 байта. Поэтому даже с правильной вершиной стека обработчики получают SP, кратный лишь 4. Исправляется одной строкой в начале программы, до разрешения прерываний: SCB->CCR |= SCB_CCR_STKALIGN_Msk; — подробнее в статье об архитектуре Cortex-M3.

Стек и куча: что проверяет компоновщик

Стек в скрипте Cortex-M не размещается как секция: его вершина — _estack в слове 0 таблицы векторов, и стек растёт вниз до тех пор, пока что-нибудь не остановит. Куча начинается сразу после статических данных: в _sbrk() из примеров STM32CubeF1 она начинается с символа end и растёт вверх, пока не дойдёт до текущего значения SP. Секция ._user_heap_stack ничего не выделяет, она лишь сдвигает счётчик адреса на _Min_Heap_Size + _Min_Stack_Size после .bss: если этот запас не помещается в RAM, компоновка закончится ошибкой. Реальный стек ею не ограничен и не измерен.

0x20005000  ← _estack: вершина стека (правильное значение)
            │  стек растёт вниз ↓
            │
            │  свободно
            │
            │  куча растёт вверх ↑ (если используется malloc)
0x20000D28  ← конец проверочного запаса ._user_heap_stack (0x600 байт)
0x20000728  ← _ebss, end, _end
            │  .bss  0x6B0 = 1712 байт
0x20000078  ← _sbss, _edata
            │  .data 0x78 = 120 байт
0x20000000  ← _sdata, начало ОЗУ

Числа здесь из примера ниже. У AVR стандартный скрипт стек не резервирует вовсе: указатель стека код запуска avr-libc ставит на __stack, по умолчанию равный RAMEND, а всё, что выше __heap_start, делят стек и куча.

Проверка: map-файл, size -A и --print-memory-usage

Map-файл — подробный отчёт компоновщика. Его включают ключом -Wl,-Map=firmware.map: GCC передаёт компоновщику всё, что после -Wl,, разбивая по запятым. В файле есть список отброшенных входных секций («Discarded input sections»), таблица областей памяти («Memory Configuration») и карта: каждая выходная секция с адресом и размером, под ней входные секции с именами объектных файлов и значения символов. Если VMA и LMA различаются, в строке секции стоит load address. Выдержка для примера ниже:

Memory Configuration

Name             Origin             Length             Attributes
FLASH            0x08000000         0x00020000         xr
RAM              0x20000000         0x00005000         xrw
*default*        0x00000000         0xffffffff

Linker script and memory map

.data           0x20000000       0x78 load address 0x08002d78
.bss            0x20000078      0x6b0
._user_heap_stack
                0x20000728      0x600

Короткую сводку даёт ключ -Wl,--print-memory-usage: для каждой области MEMORY занятый объём, размер и процент. Секции из AT>FLASH засчитываются во FLASH по LMA, так что начальные значения .data в ней учтены:

Memory region         Used Size  Region Size  %age Used
           FLASH:       11760 B       128 KB      8.97%
             RAM:        3368 B        20 KB     16.45%

Третий способ — arm-none-eabi-size -A -x firmware.elf: таблица всех секций с размерами и адресами (выдержка, отладочные секции и секции нулевого размера опущены):

firmware.elf  :
section                size         addr
.isr_vector           0x10c    0x8000000
.text                0x2a64    0x800010c
.rodata               0x1f8    0x8002b70
.ARM                    0x8    0x8002d68
.init_array             0x4    0x8002d70
.fini_array             0x4    0x8002d74
.data                  0x78   0x20000000
.bss                  0x6b0   0x20000078
._user_heap_stack     0x600   0x20000728

Чем size -A отличается от строки text data bss по умолчанию и почему её суммы приблизительны, разобрано в статье о файлах прошивки.

Пример: сколько ОЗУ остаётся стеку на STM32F103

Возьмём таблицу size -A выше (числа условные) и шаблон ST с исправленной вершиной стека 0x20005000.

Флеш-память. Последняя секция во FLASH, .fini_array, кончается на 0x08002D74 + 0x4 = 0x08002D78. С этого адреса компоновщик кладёт начальные значения .data (это и есть _sidata), ещё 0x78 байт:

Статические данные в ОЗУ — .data и .bss: 0x78 + 0x6B0 = 0x728 = 1832 байта, они кончаются на 0x20000728.

Под стек и кучу остаётся всё от конца .bss до вершины стека:

Если программа не вызывает malloc, все 18 648 байт доступны стеку. Сводка --print-memory-usage показывает для RAM 3368 байт: 1832 байта данных плюс проверочный запас 0x600 = 1536 байт из ._user_heap_stack. С неисправленным _estack = 0x20004FFF стек начнётся с 0x20004FFC, и останется 18 644 байта.

Когда сборка упадёт. Пусть .bss вырос до 0x4A00 байт: он займёт ОЗУ до 0x20004A78, проверочный запас кончится на 0x20004A78 + 0x600 = 0x20005078, что на 0x78 байт дальше конца RAM. Компоновщик напишет:

…/ld: firmware.elf section `._user_heap_stack' will not fit in region `RAM'
…/ld: region `RAM' overflowed by 120 bytes

Обратите внимание: названа секция ._user_heap_stack, хотя вырос .bss, — первой не поместилась последняя секция области. Число 120 — сколько не хватило с учётом запаса. Если уменьшить _Min_Stack_Size, сборка пройдёт, но памяти программе от этого не прибавится.

Сколько стека нужно на самом деле, компоновщик не знает. Ключ GCC -fstack-usage пишет для каждой функции размер её кадра стека в файл .su с пометкой static, dynamic или dynamic,bounded; глубину стека оценивают, складывая кадры по самой длинной цепочке вызовов и добавляя кадры прерываний, которые могут вложиться друг в друга. Про кадр прерывания на Cortex-M — в статье о прерываниях и общих данных.

Стандартный скрипт avr-gcc: что в нём иначе

AVR — микроконтроллер гарвардской архитектуры: у памяти программ и памяти данных разные адресные пространства, и адрес 0x0100 существует в обоих. Компоновщику же нужна одна шкала адресов. Поэтому стандартный скрипт binutils сдвигает данные: область data начинается не с 0, а с 0x800000 плюс начало ОЗУ, EEPROM — с 0x810000, фьюзы — с 0x820000, биты защиты — с 0x830000, сигнатура — с 0x840000, пользовательские сигнатуры — с 0x850000. Программа использует только младшие 16 бит адреса, так что сдвиг в машинный код не попадает. В выводе avr-size -A, где адреса десятичные, начало .data у ATmega328P выглядит как 8388864 — это 0x800100.

Как выглядят основные правила (фрагмент шаблона avr.sc из binutils 2.47 после подстановки переменных; многоточия и комментарии наши, часть строк опущена):

.text :
{
  *(.vectors)
  KEEP(*(.vectors))
  *(.progmem)
  *(.progmem.*)                    /* PROGMEM data, lower 64 KB */
  *(.init0) … *(.init9)            /* startup code, each with KEEP */
  *(.text) *(.text.*)
  _etext = . ;
} > text

.data :
{
  PROVIDE (__data_start = .) ;
  *(.data) *(.data*)
  *(.rodata) *(.rodata*)           /* classic AVR: constants go to RAM */
  _edata = . ;
  PROVIDE (__data_end = .) ;
} > data AT> text

.bss  ADDR(.data) + SIZEOF(.data) : AT (ADDR (.bss))   { … } > data
__data_load_start = LOADADDR(.data);
.noinit ADDR(.bss) + SIZEOF(.bss) : AT (ADDR (.noinit)) { … PROVIDE (__heap_start = .) ; } > data

Чем это отличается от STM32:

Две детали стоят отдельного внимания. Первая — константы. Команды LD классических AVR не читают флеш-память, поэтому шаблон включает .rodata в .data, если для архитектуры не задан сдвиг RODATA_PM_OFFSET или механизм FLMAP. У avr5 ни того, ни другого нет, и любая строка без PROGMEM занимает и флеш-память, и ОЗУ. У архитектуры avrxmega3 (ATtiny816, ATmega4809) задан сдвиг RODATA_PM_OFFSET, по умолчанию 0x8000, и .rodata остаётся во флеш-памяти, которую эти чипы видят в адресах данных. У ATmega4809 флеш-память видна с адреса 0x4000, поэтому avr-gcc переопределяет сдвиг ключом --defsym=__RODATA_PM_OFFSET__=0x4000 из спецификации устройства. Подробнее о PROGMEM — в статье о языке C для микроконтроллеров.

Вторая — адреса и длины областей. Начало .data у ATmega328P (0x800100) задаёт не скрипт, а драйвер avr-gcc: в спецификации устройства есть правило *link_data_start, которое передаёт компоновщику -Tdata 0x800100, если начало ОЗУ чипа отличается от умолчания архитектуры (у avr5 это 0x60, у ATmega328P — 0x100). Длины скрипт берёт из символов __TEXT_REGION_LENGTH__ и __DATA_REGION_LENGTH__, а значения по умолчанию у avr5 рассчитаны на самый большой чип архитектуры: 128 КБ и 0xFFA0 байт. Код запуска avr-libc 2.3.2 определяет эти символы по заголовку устройства: для ATmega328P это FLASHEND + 1 = 32 768 байт и RAMEND − RAMSTART + 1 = 2048 байт. Начало и длину области data код запуска задаёт, только если avr-libc собрана с binutils версии 2.40 или новее, где появился __DATA_REGION_ORIGIN__. Тогда переполнение статических данных компоновщик ловит сам. Проверка Arduino IDE по upload.maximum_data_size из boards.txt работает отдельно и описана в статье о файлах прошивки.

Пример: свободное ОЗУ ATmega328P

Пусть avr-size -A показывает .data 22 байта по адресу 8388864 (0x800100) и .bss 184 байта по адресу 8388886 (0x800116), .noinit пуста. Тогда:

• .data занимает 0x100–0x115, .bss — 0x116–0x1CD;
• __heap_start = 0x100 + 22 + 184 = 0x1CE;
• указатель стека после старта = RAMEND = 0x8FF;
• стеку и куче остаётся 0x8FF − 0x1CE + 1 = 0x732 = 1842 байта.

Это та же цифра, которую Arduino IDE называет «оставляя 1842 байт для локальных переменных». Сколько из них стек занимает на деле, можно измерить. В avr-libc 2.3 есть функция _get_ram_unused() из <util/ram-usage.h>: если она есть в программе, код запуска в .init3 закрашивает ОЗУ от __heap_start до RAMEND значением 0xAA, а функция считает, сколько байт подряд от __heap_start остались нетронутыми. Если после прогона всех режимов и прерываний она вернула 1630, стек занимал как минимум 1842 − 1630 = 212 байт. С malloc этот способ несовместим: куча растёт как раз из зоны раскраски. У malloc в avr-libc своя защита: без явной границы кучи он не заходит выше текущего SP минус __malloc_margin, по умолчанию 32 байта, — но и это не гарантирует, что стек потом не вырастет в кучу.

Своя секция: .noinit, функция в ОЗУ

Атрибут GCC section("имя") кладёт функцию или глобальную переменную в указанную секцию, а куда эта секция попадёт в памяти, решает скрипт. Два частых применения.

Переменная, которая переживает сброс. Код запуска обнуляет .bss и заполняет .data при каждом старте, поэтому для счётчика перезапусков или кода ошибки перед сбросом от сторожевого таймера нужна секция, которую он не трогает. В стандартном скрипте AVR такая секция есть — .noinit, без начальных значений и без обнуления. У GCC 16 для этого есть и атрибут noinit, который полагается на скрипт, размещающий секции .noinit. В шаблоне ST для STM32F1 правила для .noinit нет, и секция оказалась бы «сиротой» с местом, которое выбирает эвристика компоновщика. Правило лучше добавить явно, например после .bss:

  .noinit (NOLOAD) :
  {
    . = ALIGN(4);
    *(.noinit)
    *(.noinit.*)
    . = ALIGN(4);
  } >RAM

NOLOAD помечает секцию как незагружаемую: место в ОЗУ под неё при работе отводится, но содержимое при загрузке не записывается. Переменная:

#define BOOT_MAGIC 0x5AA5C33Cu

__attribute__((section(".noinit"))) static uint32_t boot_magic;
__attribute__((section(".noinit"))) static uint32_t boot_count;

void boot_counter_update(void)
{
    if (boot_magic != BOOT_MAGIC) {    /* power-on: RAM holds garbage */
        boot_magic = BOOT_MAGIC;
        boot_count = 0;
    }
    boot_count++;                      /* survives watchdog and software resets */
}

После включения питания в .noinit случайные значения, поэтому рядом хранят «магическое» число. Начальное значение такой переменной задать нельзя: avr-libc прямо пишет, что в .noinit можно класть только данные без инициализатора.

Функция в ОЗУ. Иногда код должен выполняться не из флеш-памяти, например пока флеш-память стирается. Ядро Cortex-M3 может выполнять код из области SRAM. Функцию кладут в свою секцию, а в скрипте добавляют эту секцию в правило .data, чтобы код запуска скопировал её в ОЗУ вместе с переменными:

__attribute__((section(".ramfunc"), noinline))
void flash_wait_ready(void)
{
    /* runs from RAM: copied there by the startup code together with .data */
}

  /* inside the existing .data rule, between *(.data*) and the final ALIGN(4) before _edata */
    *(.ramfunc)
    *(.ramfunc*)

Расстояние от флеш-памяти 0x08000000 до ОЗУ 0x20000000 больше дальности команды BL (±16 МБ), но вызов всё равно работает: компоновщик ARM сам вставляет промежуточную заглушку для слишком далёкого вызова. Атрибут long_call делает дальний вызов явным. Выходная секция .data с кодом внутри становится одновременно записываемой и исполняемой, поэтому ld выдаст предупреждение о сегменте с правами RWX — здесь оно ожидаемо.

Своя секция бывает нужна и для данных по фиксированному адресу, например для блока настроек в последней странице флеш-памяти: в MEMORY под неё заводят отдельную область, уменьшив FLASH, и направляют туда секцию правилом с KEEP.

Ошибки компоновщика и как их читать

Последние две строки таблицы — самые неприятные: компоновщик ошибки не видит. Map-файл стоит открывать не только после ошибки, но и после любой правки скрипта: там видно, куда легла каждая секция, сколько места съели библиотечные функции и что выбросила сборка мусора.