Потребовалось организовать в ОЗУ следующую карту памяти:
0x60-0x71 - зарезервировано
0x71-N - Массив (его размер определяется при объявлении в программе)
N-0x45F - данные программы, стеки, в общем как обычно.
Массив определяю в программе в отдельную секцию:
Код
uint8_t Buffer[5] __attribute__((section("buffer"),used));
Скопировал в каталог проекта скрипт avr4.x, изменил в нем регионы, поставил выходную секцию .bss перед .data, добавил свою секцию в .bss:
Код
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 0x17F4
data (rw!x) : ORIGIN = 0x800071, LENGTH = 1K
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 512
}
....
.bss :
{
*(buffer); /* reserved for TxBuffer */
KEEP (*(buffer))
PROVIDE (__bss_start = .);
*(.bss)
*(.bss*)
*(COMMON)
PROVIDE (__bss_end = .);
} > data
.data SIZEOF(.bss) + ADDR(.bss) : AT (ADDR (.text) + SIZEOF (.text) ) /* load from (.text) + sizeof(.text) */
{
PROVIDE (__data_start = .);
*(.data)
*(.data*)
*(.rodata) /* We need to include .rodata here if gcc is used */
*(.rodata*) /* with -fdata-sections. */
*(.gnu.linkonce.d*)
. = ALIGN(2);
_edata = .;
PROVIDE (__data_end = .);
} > data
При компиляции получаю предупреждение: ld.exe: Test.elf: warning: allocated section `.data' not in segment{
text (rx) : ORIGIN = 0, LENGTH = 0x17F4
data (rw!x) : ORIGIN = 0x800071, LENGTH = 1K
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 512
}
....
.bss :
{
*(buffer); /* reserved for TxBuffer */
KEEP (*(buffer))
PROVIDE (__bss_start = .);
*(.bss)
*(.bss*)
*(COMMON)
PROVIDE (__bss_end = .);
} > data
.data SIZEOF(.bss) + ADDR(.bss) : AT (ADDR (.text) + SIZEOF (.text) ) /* load from (.text) + sizeof(.text) */
{
PROVIDE (__data_start = .);
*(.data)
*(.data*)
*(.rodata) /* We need to include .rodata here if gcc is used */
*(.rodata*) /* with -fdata-sections. */
*(.gnu.linkonce.d*)
. = ALIGN(2);
_edata = .;
PROVIDE (__data_end = .);
} > data
При этом avr-objcopy при создании .hex добавляет в него данные по адресам __data_start (т.е. 0x8000XX). Начал урезать исходники и makefile, чтобы отыскать откуда ноги. Эффект нестабильный - при выкидывании одних кусков исходника пропадает, при выкидывании других - остается. Получил прилагаемый проект, в котором эффект еще повторяется. При дальнейшем уменьшении исходника эффект пропадает. Причем он пропадает даже при изменении той части исходника, код из которой не используется и выкидывается при линковке. Если убрать --gc-sections, эффект также пропадает. Если в линкерном скрипте убрать ". = ALIGN(2);" в .data (кстати, зачем он тут?) - тоже исчезает. Заметил, что одно из условий появления - если в результате сбора мусора линкером сегмент .data получается пустым, однако это не единственное условие, требуется что-то еще.
Пробовал версию 22071221 - поведение идентично. 20060421 - предупреждение не генерится, но в выходной .hex-файл все равно добавляется мусор.
Вопрос первый - что означает это предупреждение? Гугление не помогло.
Вопрос второй - что я делаю не так и как надо правильно добавлять свои секции?
Вопрос третий - пробовал создавать в линкерном скрипте отдельную выходную секцию для массива. В результате avr-objcopy -o ihex -R .eeprom Test.elf Test.hex помещает в .hex нули по VMA адресам этого массива. При указании -R <имя моей секции> она исчезает из выходного файла, но тогда возникет вопрос - почему в выходном файле не появляются секции .noinit, .bss и секции отладочной информации (перечислены в конце скрипта), хотя они и не были перечислены с ключем -R. Где об этом можно почитать? В документации к ld, avr-objcopy, objcopy, gcc ничего на эту тему не нашел.
На третий день до жирафа дошло, что его ноги сбил паровоз 