Линковщик IAR 7.50, Размещает секции в произвольном порядке, как сделать упорядоченно Опции

[haker_fox]

Добрый день! Столкнулся с проблемой, что линковщик ложит секции в произвольном порядке в область RAM. Это документированно, это нормально. Но не для меня

В скрипте написано так

CODE

place in RAM_region   { readwrite,
                        block CSTACK,
                         };

По факту, глядя в map я вижу, что после блока CSTACK находится секция .bss.

Я пытался её принудительно прописывать в начало (перед секциеё readwrite). Но это не меняло поведения линковщика. Читая доку, понял что можно секции ложить в блоки, но не понял как. Помогло временно сделать так

CODE

place in RAM_region   { readwrite,
                        block CSTACK };
place at start of RAM_region { zeroinit };

Теперь .bss лежить в начале ОЗУ, а блок CSTACK - последним. Но это временная мера, не гарантирующая ничего. Также в документации не нашёл, что значит

"P2", part 1 of 2:

. Т.е. получается он (линковщик) разбивает процесс укладывания секций на части? Как эти управлять? В общем я маленько в растерянности... Подскажите, пожалуйста, что я упустил в доке? Спасибо!

[bseyur]

Код

place at end of RAM_region   { block CSTACK };

Попробуйте так. Кроме того, есть директива fixed order, которая позволяет задать порядок следования секций именно в том порядке, как они объявлены в фигурных скобках. Например:

Код

define block STARTCODE_block with fixed order    { readonly section .intvec , readonly section .startcode };
place at start of ROM_region { block STARTCODE_block };

Но в любом случае правильность работы скрипта нужно контролировать по map-файлу.

[haker_fox]

CODE

place at end of RAM_region   { block CSTACK };

Попробуйте так. Кроме того, есть директива fixed order, которая позволяет задать порядок следования секций именно в том порядке, как они объявлены в фигурных скобках. Например:

CODE

define block STARTCODE_block with fixed order    { readonly section .intvec , readonly section .startcode };
place at start of ROM_region { block STARTCODE_block };

Но в любом случае правильность работы скрипта нужно контролировать по map-файлу.

Ок, спасибо!!! Попробую)

Но в любом случае правильность работы скрипта нужно контролировать по map-файлу.

Правда вот это и настараживает, как бы в релиз не ушло то. что может потенциально дать проблему

[bseyur]

Правда вот это и настараживает, как бы в релиз не ушло то. что может потенциально дать проблему

Ну практика показала, при каждой сборке не обязательно проверять, достаточно раз написать стабильно работающую конфигурацию :-)