WinAVR - проблема с секциями в ld, warning: allocated section `.data' not in segment Опции

[Сергей Борщ]

Мега 8. WinAVR 20070525.
Потребовалось организовать в ОЗУ следующую карту памяти:
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
При этом 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 ничего на эту тему не нашел.

Прикрепленные файлы

 ld_quest.zip ( 3.24 килобайт ) Кол-во скачиваний: 41

 

[Сергей Борщ]

Провел дополнительные исследования. Выяснил, что появление лишней информации в .hex и это предупреждение не связаны (хотя вчера они появлялись и исчезали одновременно). С появлением лишней информации выяснил, что если мои секции описаны в .bss между строчками PROVIDE (__bss_start = .) и PROVIDE (__bss_end = .), то они не появляются в выходном файле, если же вне этих строчек - то появляются:

Код

  .bss :  /* Так появляется */
  {
    *(buffer);    /* reserved for TxBuffer */
    KEEP (*(buffer))
     PROVIDE (__bss_start = .);
    *(.bss)
    *(.bss*)
    *(COMMON)
     PROVIDE (__bss_end = .);
  }  > data

  .bss :     /* a так - нет */
  {
     PROVIDE (__bss_start = .);
    *(buffer);    /* reserved for TxBuffer */
    KEEP (*(buffer))
    *(.bss)
    *(.bss*)
    *(COMMON)
     PROVIDE (__bss_end = .);
  }  > data

Таким образом обходное решение найдено, но остается третий вопрос - как avr-objcopy по умолчанию определяет, что включать в .hex, а что - нет.

[amw]

При компиляции получаю предупреждение: ld.exe: Test.elf: warning: allocated section `.data' not in segment

Проблема (несоответствие) адресов/размеров переменных и Memory Region.
То есть попытка разместить символ по адресу, не попападающему в соответствующий регион памяти.

Провел дополнительные исследования. Выяснил, что появление лишней информации в .hex и это предупреждение не связаны (хотя вчера они появлялись и исчезали одновременно). С появлением лишней информации выяснил, что если мои секции описаны в .bss между строчками PROVIDE (__bss_start = .) и PROVIDE (__bss_end = .), то они не появляются в выходном файле, если же вне этих строчек - то появляются:

Код

  .bss :  /* Так появляется */
  {
    *(buffer);    /* reserved for TxBuffer */
    KEEP (*(buffer))
     PROVIDE (__bss_start = .);
    *(.bss)
    *(.bss*)
    *(COMMON)
     PROVIDE (__bss_end = .);
  }  > data

  .bss :     /* a так - нет */
  {
     PROVIDE (__bss_start = .);
    *(buffer);    /* reserved for TxBuffer */
    KEEP (*(buffer))
    *(.bss)
    *(.bss*)
    *(COMMON)
     PROVIDE (__bss_end = .);
  }  > data

Таким образом обходное решение найдено, но остается третий вопрос - как avr-objcopy по умолчанию определяет, что включать в .hex, а что - нет.

Собственно __bss_start и __bss_end являются общепринятыми (в мире CGG) именами и должны обрамлять секцию. То-же касается и __data_start и прочих. Я не копал глубоко, но может эти имена анализируются линкером.
PROVIDE () больше предназначено для устранения дублирующих определений и их гарантированного появления чем для собственно определений. Что будет если PROVIDE (__bss_start = .) заменить на __bss_start = .? Сообщение останется?
objcopy по умолчанию копирует в HEX файл (как впрочем и в binary) выходные секции .text .data .rodata (полный список зависит от архитектуры).

Сообщение отредактировал amw - Mar 13 2008, 09:27

[Сергей Борщ]

Проблема (несоответствие) адресов/размеров переменных и Memory Region.
То есть попытка разместить символ по адресу, не попападающему в соответствующий регион памяти.

Пппереведи! (с)"Москва слезам не верит". Какое мое действие приводит к возникновению этого предупреждения и почему оно то появляется, то исчезает в зависимости от седержимого кода, удаляемого сборщиком мусора линкера?
Я интуитивно понял, что при какой-то комбинации сборщик мусора линкера выкидывает все из секции .data, но оставляет там байт-заполнитель от инструкции скрипта . = ALIGN(2). Предполагаю, что для этого байта нет соответствующего значения в области AT (ADDR (.text) + SIZEOF (.text), о чем и ругается линкер. Но это только мое предположение.

Собственно __bss_start и __bss_end являются общепринятыми (в мире CGG) именами и должны обрамлять секцию. То-же касается и __data_start и прочих. Я не копал глубоко, но может эти имена анализируются линкером.

Вот где про это почитать, кроме исходников линкера? В описании линкера эти символы не упоминаются, в примерах скриптов в этом же описании не встречаются, и вдруг выясняется, что они имеют важное значение. Хотелось бы ознакомиться с документами, где это описано, чтобы не двигаться наощупь. И вдруг там описано еще что-то важное и интересное.

PROVIDE () больше предназначено для устранения дублирующих определений... Что будет если PROVIDE (__bss_start = .) заменить на __bss_start = .? Сообщение останется?

PROVIDE определяет символ, если такой символ не определен в объектных файлах. В данном конкретном случае не изменилось ничего, чего и следовало ожидать.

objcopy по умолчанию копирует в HEX файл (как впрочем и в binary) выходные секции .text .data .rodata (полный список зависит от архитектуры).

- А я Виндовс-2000 так до конца и не прошел
- Так это же не игра, а операционная система!
- Откуда инфа?!?!?

Откуда инфа? Где посмотреть этот полный список? .bss, .noinit, .stab, .comment, .debug, .line - тоже выходные секции. Причем как показал мой эксперимент с перемещением __bss_start = . он может копировать выходные секции не целиком, а частями.
Кто-нибудь знает, какой конкретно TFM мне надо R?