Стартап и скрипт линкера из CMSIS для Sourcery CodeBench Опции

[koluna]

Всем привет!

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

Прикрепленные файлы

 GCC.zip ( 3.82 килобайт ) Кол-во скачиваний: 14

 

[koluna]

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

Код

.isr_vector :
{
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
} > FLASH

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

Код

.text.align :
{
    . = ALIGN(8);
    _etext = .;
    _sidata = _etext;        /* start of initialized data label */
} > FLASH

.data : AT ( _sidata )        /* AT makes the LMA follow on in the binary image */
{
    . = ALIGN(4);
    _sdata = .;                /* start of .data label */
    KEEP( *(.data) )
    KEEP( *(.data.*) )
    . = ALIGN(4);
    _edata = .;                /* end of .data label */
} > RAM

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

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

Код

KEEP(SORT(*)(.init_array))

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

Сообщение отредактировал koluna - Jun 13 2013, 18:42

[Сергей Борщ]

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

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

По VMA и LMA тоже не все понятно.
Как я понял, LMA - это адрес расположения секции в ROM, а VMA - расположения в RAM?

Да.

Используется только при создании образа в ROM для инициализации инициализированных переменных в RAM?

Чаще всего - да. Также используется для загружаемых в ОЗУ функций.

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

Верно. Антоха что-то намудрил. и .data : AT ( _sidata ) тоже не лучший вариант. Предпочитаю

CODE

.data :
{
   ......
} > RAM AT > FLASH

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

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

[koluna]

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

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

SORT is an alias for SORT_BY_NAME.

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

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

Код

...
SORT_BY_NAME(.text*)
...
SORT_BY_NAME (SORT_BY_NAME (wildcard section pattern))
....

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

Код

...
SORT(*)(.init_array)
...

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

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

Код

...
SORT( *( .init_array ) )
...

Ну, или так:

Код

...
*( SORT( .init_array ) )
...

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

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

The load address is specified by the AT or AT>
keywords. Specifying a load address is optional.
The AT keyword takes an expression as an argument. This specifies the exact load address
of the section. The AT> keyword takes the name of a memory region as an argument. See
Section 3.7 [MEMORY], page 63. The load address of the section is set to the next free
address in the region, aligned to the section’s alignment requirements.