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

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

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

Код

/* higher address of the user mode stack */
PROVIDE ( _estack = ALIGN(ORIGIN(RAM) + LENGTH(RAM) - 8 ,8) );

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

Код

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

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

Код

._usrstack :
{
    . = ALIGN(4);
    _susrstack = .;
    . = . + _Minimum_Stack_Size;
    . = ALIGN(4);
    _eusrstack = .;
} >RAM

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

Код

/* remove the debugging information from the standard libraries */
DISCARD :
{
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
}

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

Код

/* Stabs debugging sections.  */
.stab          0 : { *(.stab) }
...

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

[AHTOXA]

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

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

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

Код

/* higher address of the user mode stack */
PROVIDE ( _estack = ALIGN(ORIGIN(RAM) + LENGTH(RAM) - 8 ,8) );

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

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

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

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

Код

._usrstack :
{
    . = ALIGN(4);
    _susrstack = .;
    . = . + _Minimum_Stack_Size;
    . = ALIGN(4);
    _eusrstack = .;
} >RAM

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

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

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

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

Код

/* Stabs debugging sections.  */
.stab          0 : { *(.stab) }
...

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

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

[koluna]

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

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

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

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

Да, так. Если мы сильно захотим, то можем в программе задать свой адрес для _estack.

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

Выравнивание на 8 байт - это требование ARM EABI. Без этого бывают трудноуловимые глюки.

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

Выравнивания полезны Я не помню, зачем они в каждом конкретном случае, но хуже от них точно не будет.

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

Лично наблюдал приличное уменьшение времени переключения контекста scmRTOS при добавлении выравнивания функции переключения контекста.

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

Мусор чистит очень просто. То, что KEEP - оставляет, далее строит дерево вызовов. Всё, что не вызывается из того, что KEEP - выкидывается.

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

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

Код

._usrstack :
{
    . = ALIGN(4);
    _susrstack = .;
    . = . + _Minimum_Stack_Size;
    . = ALIGN(4);
    _eusrstack = .;
} >RAM

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

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

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