Всем привет!

Помогите разобраться, пожалуйста.
Стартап и скрипт взял из CMSIS 3.01 (\Device\ARM\ARMCM3\Source\GCC): gcc_arm.ld, startup_ARMCM3.S (приложил к теме).
Подцепляю к простейшему тестовому проекту.
При сборке линкер ругался сначала на отсутствие libnosys.a (ее действительно нет в дистрибе компилятора) - убрал ее из списка в скрипте. Ошибка пропала.
Но так и не нашел, что это за либа, для чего нужна и почему ее нет...
Потом линкер ругался на отсутствие "_start". Странно, откуда эта метка в стартапе и почему так называется? Поставил вместо нее "main" - все собралось. Ошибок нет.
Но осадок сомнения остался - уже две ошибки в этих двух файлах... кто знает, что там еще? Надеялся, что все заработает "из коробки".
Пока не зашивал, не уверен в работоспособности, будем пробовать.
Насколько можно верить этим файлам? Что еще в них придется корректировать (ну, кроме размеров RAM, ROM, размеров стека и кучи)?

Я в свое время сам писал и скрипт и стартап. Чем-то меня смсисовские не устроили.

Кстати, неясно зачем там асм. Для кортексов стартап прекрасно пишется на С...

Да я бы и сам написал, если бы знал как
Хочется разобраться, но времени пока нет.
Поэтому решил начать с более простого - подключить имеющиеся файлы.

Что, неужели "коробочные" файлы так плохи и никто их не использует?

Кто-нибудь выскажет свое мнение?
Или мир разделился на два лагеря: одни пишут скрипты/стартапы сами, другие используют среды программирования с уже имеющимися скриптами/стартапами и не заморачиваются?

Еще стартапы есть в стандартной библиотеке периферии от STM. Правда при сборке с ними ошибок гораздо больше.
И нет почему-то скриптов линкера...

Скрипты должны быть - иначе как собрать откомпилированный код?

Ясное дело, что где-то они есть - без них никак!
Я говорю о другом. В комплекте с SPL их нет. Стартапы есть, а скриптов нет.
Поэтому взял все из CMSIS. Но при сборке возникли ошибки.
Поправил. Заработало. Пока не зашивал. Не уверен в работоспособности полученного кода из-за скрипта и стартапа. Не знаю какие там могут быть ошибки еще - вот и спрашиваю у опытных людей.
Кто-нибудь использовал эти самые файлы из комплекта CMSIS с минимальными изменениями (и какими)?

Попробуйте скрипты и стартап от scmRTOS. Я точно знаю, что они рабочие

AHTOXA, спасибо большое!
Но мне хотелось бы все-таки получить ответы на свои вопросы касательно файлов из CMSIS

Кстати, какими основными принципами надо руководствоваться при написании стартапов (для Ассемблера и Си)?

AHTOXA, есть вопросы по Вашему стартапу, прошу помочь разобраться

Строки 12-23.
Что это? Где определено? В доке на компилятор не нашел.

Строки 207-454.
(intfunc)((unsigned long)&_estack) - для чего это вначале таблицы векторов?

Строки 465-487.
Тут, вроде, более менее понятно.
Инициализируем инициализируемые переменные своими значениями, инициализируем нулями неинициализируемые переменные, инициализируем железо (что конкретно только не понятно пока), инициализируем внешнюю память, если она есть, вызываем конструкторы.
init_HW() - это что-то типа SystemInit() из system_stm32f10x.c в SPL?
Вызов init_HW() до вызова конструкторов т. к., конструкторы могут работать с железом?
Видимо в scmRTOS есть реализованная функция init_HW()?

Это переменные из линкерного скрипта. Границы секций.

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


Да, всё именно так. Просто сначала я придумал название init_HW(), а потом в ST придумали SystemInit() Можете заменить одно на другое.
(Если что, то функцию init_HW() можно посмотреть здесь).

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

Не совсем понятно что это. Вроде, одно и тоже... но зачем тогда два идентификатора?


Тут правильно?




С преобразованием-то понятно, а вот с тем что первый элемент адрес стека - нет, видимо, так для ARM надо. Перечитаю про прерывания

Спасибо большое за консультации.
В общем, параллельно надо в скрипт линкера вникать

Да. Линкер знает их адреса (из скрипта). В любом месте программы вы можете объявить переменную с таким именем. (Здесь нам нужна не сама переменная, а её адрес. Хотя я видел, как в линкерном скрипте объявляли регистры процессора. В этом нет особого смысла, но это возможно ).


Там есть какой-то перечень предопределённых имён, которые нужны встроенным стартапам. Так что в скрипте объявляются разные возможные варианты, например, end и __end. Памяти они не занимают, так что не жалко.


Да, всё так.

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



А где, кстати, перечень? Может быть так много имен для совместимости?

Ну мало ли. Например, end/_end/__end часто используются менеджерами кучи.

Не уверен, что этот перечень где-то формализован. Скорее, это происходит так: перестаёт компилироваться каким-то компилятором программа - добавляем ещё одну переменную.
В общем, не надо особо с этим заморачиваться, основную идею поняли, заработало - и нормуль. Если вдруг понадобится что-то специфическое, то тогда уже погружаться, да

Понятно, спасибо
Разбираюсь с линкером потихонечку.
Будут и по нему вопросы

Вопросы по Вашему скрипту.

Зачем вообще придумали так много разных секций? Где узнать назначение каждой секции?
Секции .text, .data, .bss, .isr_vector понятно для чего.
.ARM.exidx для чего?



Зачем тут PROVIDE()?
Если в программе уже определен символ _estack, то линкер использует его. А если символ не определен, но есть ссылки на него, то линкер сам создаст этот символ. Так?
Не понял что тут с выравниванием и зачем так...



Зачем тут эти выравнивания?
Зачем вообще во всем скрипте так много выравниваний?
KEEP(), как я понимаю, нужен для того, чтобы при линковке с --gc-sections линкер не отбросил секцию .isr_vector?
Не совсем понятно как он чистит мусор.



_Minimum_Stack_Size, это размер стека?
_susrstack и _eusrstack могут использоваться программой для отслеживания переполнения стека?



Как я понимаю, все входные секции, перечисленные в выходной секции DISCARD не попадают в выходной файл. Здесь - все секции из перечисленных файлов.
А почему в комментарии это названо отладочной информацией? Что-то я не понимаю, мы же используем эти библиотеки, а если мы их используем, то не мешает ли выше перечисленное?!
Или получается так, что ранее мы уже включили все нужное нам из этих библиотек в выходной файл (секции .text, .data, .bss) и все что остается - нам не нужно?



Почему мы все располагаем по адресу "0"?

Ничего себе, сколько вопросов
Сразу предупреждаю, так глубоко я не копал, так что не на все вопросы у меня есть ответы.

Это что-то связанное с обработкой исключений. Хотя мы отключаем эту обработку, всё равно что-то иногда пролазит. Короче, без этой секции какой-то из линкеров не собирал.

Да, так. Если мы сильно захотим, то можем в программе задать свой адрес для _estack.
Выравнивание на 8 байт - это требование ARM EABI. Без этого бывают трудноуловимые глюки.

Выравнивания полезны Я не помню, зачем они в каждом конкретном случае, но хуже от них точно не будет.
Лично наблюдал приличное уменьшение времени переключения контекста scmRTOS при добавлении выравнивания функции переключения контекста.
Мусор чистит очень просто. То, что KEEP - оставляет, далее строит дерево вызовов. Всё, что не вызывается из того, что KEEP - выкидывается.

Здесь простейшая проверка, что перед _eusrstack у нас останется _Minimum_Stack_Size свободного места. Если не останется, то линкер ругнётся.

Да, всё полезное из этих файлов мы уже забрали выше.

Тут ничего не скажу, не знаю. Этот кусок есть во всех скриптах, которые я видел, поэтому он, наверное, нужен

Я посмотрел на скрипт внимательно, почитал доку на линкер и понял, что надо позадавать еще вопросов



Зачем вообще она нужна для ARM? Почему ее полностью не отключат изначально? Или тулчейн один и на мелкие процы, и на крупные процы, а на крупных обработка исключений в ходу, в отличие от мелких?



Ууу... что, может понадобиться?



Ветку почитаем, спасибо. Пруфлинк можно про выравнивание, пожалуйста?



Дырки в памяти образуются И большое количество команд выравнивания вводит в ступор: не понимаешь для чего это и почему именно так и нужно ли вообще...
А хочется все понимать...



Может, связано с выборкой команд? Ну там... ARM-инструкции (32 бита), THUMB-инструкции (16 бит)... т. е., адрес расположеня должен почему-то быть кратным 4 или 2 байтам...



Т. е., то, на что есть ссылки в коде и то, что обрамлено KEEP оставляется, все остальное - выкидывается?





Как я понимаю, эта секция - последнее, что будет размещено в RAM. И, если не хватит места для ее размещения, то линкер об этом сообщит?
Фактически мы проверям (на этапе линковки), что размер стека будет не менее чем _Minimum_Stack_Size?
А во время выполнения программы?
Стек ведь может переполниться...



Как я понимаю, это влияет на размер бинаря. А еще что на размер влияет?
Встречал где-то, что многие сталкиваются с "раздуванием" бинаря при использовании Си++, но сам пока не изучал вопрос.

GCC один на все, видимо есть места, где эти исключения никак не выпилить при портировании.

Ну мало ли. Возможность не помешает

Дык, там же, во втором сообщении темы: Eight-byte Stack Alignment

Да.

Ну, время выполнения - это уж никак не забота линкера

Не бинаря, а elf. При прошивке вся эта ботва всё равно выкидывается.
Насчёт раздувания при использовании Си++ - не замечал такого. Если не подцепились исключения, то всё очень компактно получается.

Мне вот пригодилась кое-где. Хотите отключить вообще - наверное можно и так собрать тулчейн, просто зачем?



Есть флаги компиляции, которые заведуют разбиением на секции - -ffunction-sections, --fdata-sections и флаг линкера --gc-sections


А во время выполнения программы - нужны динамические проверки. К примеру в конце стека размещаем некий паттерн, а потом периодически проверяем, что паттерн не затерт...



Я столкнулся
Включение исключений добавляют несколько десятков килобайт, включение rtti - дает накладные расходы на каждый тип с виртуальными функциями. Использование чего-то вроде iostream - дает еще порядка 150 килобайт А это включение происходит в потрохах стандартной библиотеки при включении исключений. Так как исключения мне были нужны, пришлось немного подхачить libc++.

Ну а дальше - как обычно, чем больше кода, тем больше размер. При этом надо учитывать, что какой-то код генерится автоматически - вроде инстанцирования шаблонов.

Итого, если отключить rtti и исключения - оверхеда по сравнению с С нет. Если включить и использовать stl - тут уже надо сравнивать с аналогичным рукопашным кодом на С. Ну и мозг надо не выключать

Вот здесь зачем выравнивание перед таблицей векторов?
Ведь по адресу 0 должен сохраняться указатель начального адреса стека, но он уже включен в таблицу из .isr_vector.



По VMA и LMA тоже не все понятно.
Как я понял, LMA - это адрес расположения секции в ROM, а VMA - расположения в RAM?
Используется только при создании образа в ROM для инициализации инициализированных переменных в RAM?



Т. е., выше перечисленное следует понимать как-то так.
Размещаем образ для ининицилизации переменных после чудной секции .ARM.exidx (опять с непонятным выравниванием на 8) во FLASH. Тут у нас используется LMA.
Размещаем данные (хотя, наверное, не размещаем, а резервируем место для размещения) с выравниванием 4 (т. е., от начала RAM адрес расположения переменных будет 4) в RAM. Тут у нас используется VMA.

Кстати, зачем .data обертывать в KEEP()? В этих секциях ведь находятся данные, на которые мы ссылаемся, поэтому линкер не должен их выбрасывать при чистке мусора. Или я чего-то не допонял



Какой смысл в сортировке файлов при размещении статических конструкторов?

Считайте это перестраховкой. Чтобы когда захочется эту программу использовать с загрузчиком и адрес начала региона будет задан не 0 и, возможно, не кратным 4, программа продолжала собираться в рабочее состояние. Чтобы в варианте с загрузчиком, добавление секции перед этой .isr_vector не ломало программу.

Да.
Чаще всего - да. Также используется для загружаемых в ОЗУ функций.
Верно. Антоха что-то намудрил. и .data : AT ( _sidata ) тоже не лучший вариант. Предпочитаю


кто-то может использовать для задания порядка вызова конструкторов. Т.е. Объект ADC будет создан до объекта UART. Но по секркту - это рудимент от найденного в интернете образца скрипта Не мешает.

Ох, дались вам эти выравнивания Если мы 0 выровняем на 4, то останется 0, так что дырки не будет. А вот если мы будем размещать .isr_vector где-то в другом месте, то выравнивание необходимо.

Да, всё верно.

Нет, выравнивание на 4 - это не то же самое, что отступ на 4:) Если начало ОЗУ выровнено на 4 (а обычно так и есть), то никакого отступа не будет.

Тут я не помню, если честно. Вроде бы это я боролся с LTO. И вроде бы, без этого линкер что-то выкидывал нужное. Но точно не помню, могу и соврать.

Удобно, чтоб по алфавиту вызывались.


С KEEP() я написал выше, хотя может и правда намудрил А чем хуже вариант с ".data : AT ( _sidata )" ? Мне он кажется как-то понятнее по записи.

А как, при такой записи, определить по какому адресу FLASH эти данные расположились?


Если SORT убрать, то будут вызываться в порядке появления в cpp файле?

Вот смотрю я доку на линкер и не понимаю (Sourcery Codebench)...


Ну тут понятно.

В доке все время упоминается синтаксис вида:


Т. е., SORT обрамляет шаблон секций.
А в скрипте - SORT обрамляет шаблон файлов:


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

В моем понимании надо делать как-то так:


Ну, или так:




Видимо, линкер разместит эти данные во FLASH сразу за предыдущей секцией, размещенной во FLASH.

Ааа... понял... выравнивание и отступ - разные вещи
Если счетчик позиций == 0, ALIGN( 4 ) == 0.
Если счетчик позиций == 3, ALIGN( 4 ) == 4.
Если счетчик позиций == 4, ALIGN( 4 ) == 4.
Если счетчик позиций == 5, ALIGN( 4 ) == 8.
Если счетчик позиций == 7, ALIGN( 4 ) == 8.
И т. д.

Ну а отступ, это было бы что-то вроде: ". += <отступ>;"

Выравнивание начала ОЗУ на 4 тоже требование ARM EABI, как и выравнивание начала стека на 8 байт?

Так, т. е., выравнивание таблицы векторов, начала стека и начала ОЗУ - обязательные требования, получается?

Исходя из скрипта, куча начинается сразу за неинициализированными данными и растет вверх навстречу стеку?
Чтобы стек и куча не пересеклись используются менеджеры кучи?

Да

Нет, я такого требования не припоминаю. Скорее, это сделано для удобства инициализации данных (чтоб копировать данные по слову).

Начала стека - да. Начала ОЗУ - нет (вроде). А вот с таблицей векторов на самом деле требования гораздо жестче. Нужно выравнивать на ближайшую степень двойки, большую размера таблицы векторов. Так что мы недовыравнивали

Да, всё так.

Тем, что если захочется добавить еще одну секцию между .text и .data - то придется заводить еще один символ, аналогичный _sidata и вписывать его сюда вместо _sidata. В случае же "AT > " ничего этого делать не нужно, все происходит автоматически.




Да. А для разных единиц компиляции порядок не определен. Вот для этого и делается сортировка по именам файлов (спасибо koluna, что обратил внимание). Сортировать по именам секций смысла нет, ибо все конструкторы помещаются в одну секцию, сортировать нечего.

А, точно! Вот значит почему я в скрипте для F4 сделал с "AT > " -- чтоб не заводить ещё один символ для ramfunc. Хорошая болезнь - склероз (Но символ _sidata всё-таки вручную там завёл, не подумал про LOADADDR()).

Это не я спрашивал, а Terminator

Недовыравнивали - ошибка?
Т. е., первый ". = ALIGN(4);" в секции должен выравнивать по-другому?
Хитрые там вычисления какие-то и зависят от количества векторов почему-то...

Кстати, выравненное смещение этим самым хитрым образом нужно записать в регистр VTOR, как я понимаю.
Где осуществляется запись? В стартапе и в init_HW() не нашел. Или используется значение по умолчанию?


Проекты с данным скриптом нормально собираются в Sourcery CodeBench?
Какими компиляторами собирается без проблем?

Кстати, точка входа, как я понимаю для проекта с данным скриптом будет - первый байт в секции .text?

Давайте лучше применим терминологию Сергея Борща, и скажем: "недомудрил"
То есть, скрипт рассчитан на размещение приложения по умолчанию, но в нём были приняты некоторые меры для более лёгкой его адаптации для приложений, загружаемых по другим адресам. И меры эти - оказались недостаточными.

Насколько я понял, это необходимо, чтобы адрес любого вектора из таблицы своими старшими битами совпадал с VTOR. Типа, контроллер прерываний вычисляет адрес вектора как VTOR | (номер_прерывания * 4).
Но у меня чисто теоретические познания в этой области, я не писал загрузчиков и приложений под них. Надеюсь, Сергей Борщ что-нибудь добавит.

Да, по умолчанию.

Sourcery я давно не проверял, старыми собиралось нормально. Недавно проверял с Yagarto - работало. А сам на постоянной основе использую kgp и gcc-arm-embedded, которую здесь ещё называют Linaro (что не совсем верно, имхо).

Точка входа будет вот такая:

Давайте применим
Все хорошо, спасибо Вам и всем окружающим!
Достаточно полезная беседа получается!



Подождем



Из доки на линкер.


Как я понимаю, наш случай - предпоследний?
Так... а по логике вещей при включении должно генерироваться прерывание сброса, где мы как раз и попадаем в Reset_Handler().
Ну а зачем тогда команда ENTRY и вообще разговоры об этом?


Кстати, атрибуты регионов здесь зачем?


Как я понимаю, если линкер встречает входную секцию, которая не замаплена на выходную секцию, то он создаст выходную секцию с именем входной секции и подберет регион памяти для ее расположения с участием этих атрибутов?

Нет. Потому что в начале секции .text у нас лежит начальный стек. В принципе, всё работало и без строчки
ENTRY(Reset_Handler)
в скрипте. Но отладка при этом глючила.
Зачем нужны атрибуты регионов - я не задумывался, есть и есть

Из описания VTOR:
Собственно тут все сказано: выравнивание должно быть на 128 байт.
Нет. Но в двух словах: программа будет работать в железе и без строчки ENTRY(), ибо старт с вектора по адресу 0x00000004 в процессоре прибит гвоздями. Эта строка (в приведенном AHTOXой виде) нужна отладчику, ибо он не умеет (пока) брать стартовый адрес из таблицы векторов, а пытается, по старинке, считать код команды по адресу 0. А у Cortex там лежит начальное значение указателя стека и получается конфуз.

Понятно, то есть, вариативность в описании от АРМовцев - это для производителей проца. А ST сделал жёстко 128 слов, убрав ещё пару младших битов у VTOR. С точки зрения написания линкерных скриптов это хорошо: надо просто поменять выравнивание с 4 на 512:)

Именно!

Да, виноват, ошибся. 128 слов, 512 байт.
Да я вам больше скажу: они там сами никак не определятся. На картинке замаскированы 9 бит, а полностью описание звучит так:
Так все-таки 29:11 или 29:9? Судя по последующим "Bits 10:0" маскируются 11 бит и выравнивание должно быть на 2048 байт. "Ребус, краксворд!".

Так, я где здесь начальный стек? Вижу конструкторы вначале.

А, ну да. Тогда тем более не "предпоследний случай".

В PM0214 (Programming manual для F4) всё однозначно:

Видимо была опечатка в предыдущих PM.

О счетчике позиций.

Может быть вот это:


было бы правильнее сделать так:


Есть определенные сомнения после прочтения документации.

Похоже, что так.

Вот ведь дилемма... С одной стороны, "возможны проблемы", а с другой - "работает - не трогай!"

Да, надо поправить.

Не совсем разобрался с адресацией: абсолютная и относительная.
Как я понял, вне описания секций адресация абсолютная, внутри описания секций - относительная.
Вот в чем проблема. Если внутри секций мы присваиваем значение счетчика позиций (или просто число) какому-нибудь символу, то присваевается относительный адрес (адрес относительно начала секции).



Потом в программе (в первую очередь в стартапе) мы используем эти символы.
Но адреса-то они содержат относительные! Программе, как я понимаю, нужны абсолютные адреса?

Нет. Это адрес в выходной секции (в нашем случае это FLASH или RAM):

Знаю. Но тогда это что значит?

Пока так и не понял, "--gc-sections" работает без "-ffunction-sections и -fdata-sections"?
Ну поместит компилятор при использовании ключей "-ffunction-sections и -fdata-sections" каждую функцию в ".text.имя_функции", и каждую переменную (глобальную или статическую) в ".data.имя_переменной" (".bss.имя_переменной") и что дальше?
Или линкер не может отбросить при оптимизации функции и просто переменные, которые не используются в программе, т. е., он может отбросить только секции, в которые компилятор и помещает функции/переменные при использовании ключей "-ffunction-sections и -fdata-sections"?

А фиг его знает. Либо меня подводит мой англицкий, либо там написана неправда.
Но по факту точка - это адрес в области, куда помещается секция. Может быть, дело в ">"? Там примеры без ">".

Да, линкер умеет отбрасывать только секции.

Вот и я сомневаюсь... предлагаю подождать Сергея



В итоге.
Секции, перечисленные в команде KEEP() не отбрасываются линкером при чистке мусора (актуально при компиляции с опциями “-ffunction-sections”, “-fdata-sections” и одновременной линковке с опцией “--gc-sections”). При компиляции с опциями “-ffunction-sections” и “-fdata-sections” компилятор помещает каждую функцию и переменную в отдельную секцию вида “.text.имя”, “.data.имя”, “.bss.имя”. Далее, при линковке с опцией “--gc-sections”, линкером отбрасываются все эти входные секции, на которые нет ссылок в программе (нет ссылок на функции и переменные, содержащиеся в них), кроме помеченых KEEP().
Правильно?

Да, всё так.

Я пас.

Да.