.init_array - конструкторы EABI.
.ctors - конструкторы не EABI.
Для совместимости лучше использовать в скрипте и то и другое?
.dtors
Деструкторы. EABI? Нет? Все?
Это зачем?
.comment
.line
Полная версия этой страницы: Стартап и скрипт линкера из CMSIS для Sourcery CodeBench
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Мучает меня вопрос по секциям все-таки...
.init_array - конструкторы EABI.
.ctors - конструкторы не EABI.
Для совместимости лучше использовать в скрипте и то и другое?
.dtors
Деструкторы. EABI? Нет? Все?
Это зачем?
.comment
.line
.init_array - конструкторы EABI.
.ctors - конструкторы не EABI.
Для совместимости лучше использовать в скрипте и то и другое?
.dtors
Деструкторы. EABI? Нет? Все?
Это зачем?
.comment
.line
Цитата(koluna @ Jun 19 2013, 00:37) 
.init_array - конструкторы EABI.
.ctors - конструкторы не EABI.
Для совместимости лучше использовать в скрипте и то и другое?
.ctors - конструкторы не EABI.
Для совместимости лучше использовать в скрипте и то и другое?
Можно использовать. Насчёт "лучше" - не уверен. Зачем поддерживать такие старые компиляторы?
Цитата(koluna @ Jun 19 2013, 00:37)
.dtors
Деструкторы. EABI? Нет? Все?
Деструкторы. EABI? Нет? Все?
Деструкторы нам не нужны. Поэтому мы их игнорируем, где бы они не были размещены.
Цитата(koluna @ Jun 19 2013, 00:37)
Это зачем?
.comment
.line
.comment
.line
Не знаю, и знать не хочу!
Цитата(AHTOXA @ Jun 18 2013, 23:44)
Можно использовать. Насчёт "лучше" - не уверен. Зачем поддерживать такие старые компиляторы?
Насколько старые?
Просто встречаю в других скриптах... видимо, авторы не особо задумывались над этим...
Цитата
Деструкторы нам не нужны. Поэтому мы их игнорируем, где бы они не были размещены.
И деструкторы тоже встречаю в других скриптах...
Ну, да... по сути и не нужны деструкторы для глобальных и статических объектов.
Но вдруг у кого-то фантазия проснется и он решит вызвать деструктор?
Цитата
Не знаю, и знать не хочу!
А вот я хочу, это бодрит
Со счетчиком позиций вопрос пока открыт
Цитата(koluna @ Jun 19 2013, 13:41)
Насколько старые?
Емнимс, уже года три-четыре как перешли на eabi.
Цитата(koluna @ Jun 19 2013, 13:41)
Но вдруг у кого-то фантазия проснется и он решит вызвать деструктор?
Вызвать вручную -- без проблем. Та секция отвечает за автоматический вызов деструкторов при завершении программы.
Цитата(koluna @ Jun 19 2013, 13:41)
А вот я хочу, это бодрит
Мне кажется, что вы уже достаточно прокачали свой уровень по скрипту и стартапу, и уже можно смело двигаться дальше
Цитата(koluna @ Jun 19 2013, 13:41)
Со счетчиком позиций вопрос пока открыт
По факту всё работает как надо. Скорее всего либо мы что-то не так поняли в описании, либо там (в описании) ошибка.
Цитата(AHTOXA @ Jun 19 2013, 12:04)
Емнимс, уже года три-четыре как перешли на eabi.
Теперь все поддерживаемые (развиваемые) в данный момент компиляторы компиляторы стали EABI?
Цитата
Вызвать вручную -- без проблем. Та секция отвечает за автоматический вызов деструкторов при завершении программы.
А, ну да...
Если хотим автоматом, то используем в скрипте входные секции ".dtors*" (мапим входные куда-нибудь в ".text", наверняка даже с KEEP()). Создаем символы, указывающие на начало и конец области размещения деструкторов в этих секциях, а потом в стартапе после вызова main() в цикле вызываем все деструкторы по указателю, используя выше определенные символы...
Кстати, в ".ctors" (для EABI ".init_array") помещаются только конструкторы по умолчанию, а остальные конструкторы попадают в ".text*"?
А деструкторы-то куда компилятор пихает? По аналогии с конструкторами в ".dtors*"?
Цитата
По факту всё работает как надо. Скорее всего либо мы что-то не так поняли в описании, либо там (в описании) ошибка.
Вот-вот... не понятно...
Кстати, зачем такой префикс жуткий "arm-none-eabi-"? И что вообще означает "none-eabi"? Похоже на "не EABI", но ведь компилятор мой однозначно EABI!
Читал, что такой префикс придумали, чтобы отличать от других компиляторов. Но неужели нельзя было придумать что-нибудь покороче и попроще, без двусмысленности?
QUOTE (koluna @ Jun 19 2013, 12:44)
Кстати, в ".ctors" (для EABI ".init_array") помещаются только конструкторы по умолчанию, а остальные конструкторы попадают в ".text*"?
Поскольку конструкторы являются кодом - они помещаются в .text В .init_array и .ctors в нужном порядке помещаются указатели на них. Собственно вот код их вызова, по нему все понятно:CODE
extern void(* const __ctors_start__[])();
extern void(* const __ctors_end__[])();
...
/* Call constructors */
void(* const *ctor)();
for( ctor = __ctors_start__; ctor < __ctors_end__; )
(*ctor++)();
extern void(* const __ctors_end__[])();
...
/* Call constructors */
void(* const *ctor)();
for( ctor = __ctors_start__; ctor < __ctors_end__; )
(*ctor++)();
QUOTE (koluna @ Jun 19 2013, 12:44)
Кстати, зачем такой префикс жуткий "arm-none-eabi-"? И что вообще означает "none-eabi"?
Это два префикса. -none и -eabi. Гляньте сюда.
Понятно, спасибо.
А с деструкторами все-таки что? Аналогично?
Для EABI и не EABI одинаково?
А с деструкторами все-таки что? Аналогично?
Для EABI и не EABI одинаково?
QUOTE (koluna @ Jun 19 2013, 15:31)
А с деструкторами все-таки что? Аналогично?
Мы их не используем, потому и не разбирались. Вы можете сами провести такое исследование и огласить результат.
Судя по всему для EABI, по аналогии с конструкторами (".init_array"), для деструкторов используется ".fini_array".
Вот на эту тему: http://electronix.ru/forum/index.php?showt...=79902&st=0.
Вот на эту тему: http://electronix.ru/forum/index.php?showt...=79902&st=0.
Что такое common-символы (секция COMMON)?
Из доки на линкер толком не понял.
Это к вопросу зачем нужно делать *(COMMON).
Но что такое "общие символы (common)" - не раскрывается
Из доки на линкер толком не понял.
Это к вопросу зачем нужно делать *(COMMON).
Цитата
В некоторых форматах объектных файлов общие символы (common) не привязаны к конкретной секции, поэтому линкер, считает, что они находятся в секции COMMON. Следовательно, чтобы использовать эти символы необходимо применить выражение вида *(COMMON).
Но что такое "общие символы (common)" - не раскрывается
И все-таки хотелось бы немного поговорить и о скрипте из моего первого поста (скрипт и стартап в архиве).
Без этого тема не будет для меня закрыта. Уж извините меня
Это, как я понял, для того, чтобы в командной строке библиотеки не подключать.
Что за библиотека "libnosys.a", которой нет? Насколько она нужна?
Выравнивания для таблицы векторов здесь нет. Как я понимаю, выравнивание в стартапе. Но на 2, а не на 512 байт.
Хотя скрипт ведь не заточен конкретно под STM...
Рудименты "*(.ctors) и *(.dtors)" от не EABI-компиляторов достались, судя по всему?
Для чего "crtbegin", "crtend"? В скрипте от scmRTOS этого нет.
Так и не понял, нужны ли входные секции ".eh_frame" и ".eh_framehdr" или нет...
Что-то для этих исключений сделано много непонятных секций... что вызывает уйму вопросов... а исключения в основном не используются...
Вот тут секция "vtable" используется, нужна ли она все-таки или нет? Помню, находил сообщение, где Сергей Борщ писал о том, что у него без этой секции все работает (таблица виртуальных функций помещается в ".rodata").
Входные секции ".preinit_array", ".init_array.*", ".fini_array.*", содержащие указатели на конструкторы, деструкторы (и что еще для ".preinit_array"?) размещаются в RAM. Наверное, это добавляет быстродействия, но заметно убавляет RAM, если объектов много... так что, лучше бы их было разместить во FLASH?
Выходные секции ".heap" и ".stack_dummy" создаются для того, чтобы на этапе линковки уже быть уверенным в том, что хватит места для стека и кучи (просто предполагаем, что для стека и кучи нам потребуется столько-то байт)?
Такое ощущение, что скрипт нужно допиливать
Без этого тема не будет для меня закрыта. Уж извините меня
Код
/* Library configurations */
GROUP(libgcc.a libc.a libm.a libnosys.a)
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
{
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
{
__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" создаются для того, чтобы на этапе линковки уже быть уверенным в том, что хватит места для стека и кучи (просто предполагаем, что для стека и кучи нам потребуется столько-то байт)?
Такое ощущение, что скрипт нужно допиливать
Посмотрел у себя файлы crt* в папках компилятора:
Вот, нагуглилось:
http://gcc.gnu.org/onlinedocs/gccint/Initialization.html
http://l4u-00.jinr.ru/usoft/WWW/www_debian.../elf/node4.html
Правильно ли я понимаю, что файлы эти отвечают только за вызов конструкторов и деструкторов (формирование функций _init(), _fini())?
В конечном итоге получается что-то типа этого (обработчик сброса в стандартном стартапе):
Код
find /home/koluna/soft/arm/arm-2013.05/ -name crt*
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb2/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/armv6-m/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtn.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crti.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/thumb/crtend.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtbegin.o
/home/koluna/soft/arm/arm-2013.05/lib/gcc/arm-none-eabi/4.7.3/crtend.o
Вот, нагуглилось:
http://gcc.gnu.org/onlinedocs/gccint/Initialization.html
http://l4u-00.jinr.ru/usoft/WWW/www_debian.../elf/node4.html
Правильно ли я понимаю, что файлы эти отвечают только за вызов конструкторов и деструкторов (формирование функций _init(), _fini())?
В конечном итоге получается что-то типа этого (обработчик сброса в стандартном стартапе):
Код
void Reset_Handler( void )
{
_init();
ИнициализацияЖелеза();
main();
_fini();
}
{
_init();
ИнициализацияЖелеза();
main();
_fini();
}
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.