Стартап и скрипт линкера из 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

[AHTOXA]

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

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

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

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

Размещаем данные (хотя, наверное, не размещаем, а резервируем место для размещения) с выравниванием 4 (т. е., от начала RAM адрес расположения переменных будет 4) в RAM.

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

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

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

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

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

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

Код

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

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

[koluna]

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

...

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

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

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

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

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

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

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