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

И все-таки хотелось бы немного поговорить и о скрипте из моего первого поста (скрипт и стартап в архиве).
Без этого тема не будет для меня закрыта. Уж извините меня

Код

/* Library configurations */
GROUP(libgcc.a libc.a libm.a libnosys.a)

Это, как я понял, для того, чтобы в командной строке библиотеки не подключать.
Что за библиотека "libnosys.a", которой нет? Насколько она нужна?

CODE

.text :
{
KEEP(*(.isr_vector))
*(.text*)

KEEP(*(.init))
KEEP(*(.fini))

/* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)

/* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)

*(.rodata*)

KEEP(*(.eh_frame*))
} > FLASH

Выравнивания для таблицы векторов здесь нет. Как я понимаю, выравнивание в стартапе. Но на 2, а не на 512 байт.
Хотя скрипт ведь не заточен конкретно под STM...
Рудименты "*(.ctors) и *(.dtors)" от не EABI-компиляторов достались, судя по всему?
Для чего "crtbegin", "crtend"? В скрипте от scmRTOS этого нет.

Так и не понял, нужны ли входные секции ".eh_frame" и ".eh_framehdr" или нет...
Что-то для этих исключений сделано много непонятных секций... что вызывает уйму вопросов... а исключения в основном не используются...

CODE

.data : AT (__etext)
{
__data_start__ = .;
*(vtable)
*(.data*)

. = ALIGN(4);
/* preinit data */
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP(*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);

. = ALIGN(4);
/* init data */
PROVIDE_HIDDEN (__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);

. = ALIGN(4);
/* finit data */
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP(*(SORT(.fini_array.*)))
KEEP(*(.fini_array))
PROVIDE_HIDDEN (__fini_array_end = .);

. = ALIGN(4);
/* All data end */
__data_end__ = .;

} > RAM

Вот тут секция "vtable" используется, нужна ли она все-таки или нет? Помню, находил сообщение, где Сергей Борщ писал о том, что у него без этой секции все работает (таблица виртуальных функций помещается в ".rodata").
Входные секции ".preinit_array", ".init_array.*", ".fini_array.*", содержащие указатели на конструкторы, деструкторы (и что еще для ".preinit_array"?) размещаются в RAM. Наверное, это добавляет быстродействия, но заметно убавляет RAM, если объектов много... так что, лучше бы их было разместить во FLASH?

Выходные секции ".heap" и ".stack_dummy" создаются для того, чтобы на этапе линковки уже быть уверенным в том, что хватит места для стека и кучи (просто предполагаем, что для стека и кучи нам потребуется столько-то байт)?

Такое ощущение, что скрипт нужно допиливать

Сообщение отредактировал IgorKossak - Jun 21 2013, 12:07

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!