Полная версия этой страницы: GNUARM 4.1.0. обнуление неинициализированных переменных
Собираю библиотеку стороннего разработчика. В библиотеке сделано предположение, что все неинициализированные вручную переменные содержат нули. При старте программы сегмент bss инициализируется нулями до вызова main(). Однако компоновщик по каой-то причине располагает неинициализированные переменные в сегмент data. Зато если вручную проинициализировать переменные нулями, то они ложатся в bss (почему так???). Как сказать компоновщику, что неинициализированные данные должны лежать в bss.
А если попробовать
?
Код
int some_variable __attribute__ ((section (".bss")));
?
Цитата(ArtemK @ Jun 9 2006, 12:27) 
Собираю библиотеку стороннего разработчика. В библиотеке сделано предположение, что все неинициализированные вручную переменные содержат нули. При старте программы сегмент bss инициализируется нулями до вызова main(). Однако компоновщик по каой-то причине располагает неинициализированные переменные в сегмент data. Зато если вручную проинициализировать переменные нулями, то они ложатся в bss (почему так???). Как сказать компоновщику, что неинициализированные данные должны лежать в bss.
Написать свой скрипт для линкера. В этом случае все будет под Вашим котролем, в том числе и bss.
Цитата(beer_warrior @ Jun 9 2006, 15:08)
А если попробовать
?
Код
int some_variable __attribute__ ((section (".bss")));
?
Оно и так, скорее всего, в .bss, но если в скрипте линкера, который используется по умолчанию есть что-то вроде:
Код
.data {
*(.bss)
} > ram
*(.bss)
} > ram
То что бы Вы ни делали, а bss все-равно ляжет в .data. Нужно править скрипт линкера.
Библиотека, с которой у меня были проблемы - это ucGUI 3.24. Отыскал по тексту все переменные, которые читаются до инициализации, вставил инициализацию руками в текст программы. Однако все же остались проблемы с менеджером динамической памяти. Программа могла некоторое время работать, но в какой-то прекрасный момент все крушилось именно при вызове функций выделения памяти.
Библиотека использует собственную реализацию менеджера динамической памяти. Для этой цели выделяется два массива фиксированного размера (задается на этапе компиляции) - массив дескрипторов и, собственно, куча. При вызове функции _Alloc(), отыскивается свободный дескриптор, затем дырка подходящего размера в куче, данная область помечается как занятая и возвращается номер дескриптора, соответстующий выделенному участку кучи. Номер дескриптора с помощью макроса можно преобразовать в указатель на void.
Переписал данный модуль таким образом, чтобы использовались функции malloc() и free() из sdlib вместо собственной реализации на статическом массиве. Все заработало, однако значительно медленнее, чем на реализации микриума.
Только после того, как проделал это, обнаружил в map-файле программы, что массив с кучей ложится в сегмент COMMON, причем COMMON начинается с адреса 0x00000000, а ОЗУ у меня начинается с 0x48000000. После того, как подправил скрипт линкера и указал расположение сегмента COMMON все заработало. Раньше я считал, что сегмент COMMON, если это не указано в скрипте линкера особо, должен ложится после сегмента bss. Разве нет?
Библиотека использует собственную реализацию менеджера динамической памяти. Для этой цели выделяется два массива фиксированного размера (задается на этапе компиляции) - массив дескрипторов и, собственно, куча. При вызове функции _Alloc(), отыскивается свободный дескриптор, затем дырка подходящего размера в куче, данная область помечается как занятая и возвращается номер дескриптора, соответстующий выделенному участку кучи. Номер дескриптора с помощью макроса можно преобразовать в указатель на void.
Переписал данный модуль таким образом, чтобы использовались функции malloc() и free() из sdlib вместо собственной реализации на статическом массиве. Все заработало, однако значительно медленнее, чем на реализации микриума.
Только после того, как проделал это, обнаружил в map-файле программы, что массив с кучей ложится в сегмент COMMON, причем COMMON начинается с адреса 0x00000000, а ОЗУ у меня начинается с 0x48000000. После того, как подправил скрипт линкера и указал расположение сегмента COMMON все заработало. Раньше я считал, что сегмент COMMON, если это не указано в скрипте линкера особо, должен ложится после сегмента bss. Разве нет?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.