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?

[singlskv]

А почему не сделать просто в Makefile ? :

Код

.....................
## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=  -Wl,-Map=Pd105Gcc.map
LDFLAGS += -Wl,-section-start=.data=0x800070
LDFLAGS += -Wl,-section-start=buffer=0x800060

## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom -R buffer

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0
............................

##Link
$(TARGET): $(OBJECTS)
     $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
    avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< $@

%.eep: $(TARGET)
    avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@
.......................

в HEX_FLASH_FLAGS просто удаляем секцию buffer при создании hex

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

А почему не сделать просто в Makefile ?

Потому что буфер находится внутри выходной секции .bss, а ключ -R применяется к выходным, а не входным секциям.
В первом варианте, когда это у меня вылезло, у меня под буфер была выделена отдельная выходная секция и мне ReAl как раз такое решение и посоветовал. Но мое чувство прекрасного воспротивелось этому - если objcopy умеет по умолчанию выкидывать какие-то секции, то пусть и мой буфер выкинет заодно. Для этого я и поместил его в .bss. Вылез подводный камень. Хочу разобраться.

Методом тыка дошел до того, что в прилагаемом файле.

Спасибо, посмотрю.

К стати у меня на Debian Ваш пример компилится/линкуется без ошибок и варнингов.

Надо будет проверить. Как раз недавно поставил Кубунту дома, осваиваю.

Как вариант, попробуйте чистый C.

Нет, уж лучше вы к нам

Собственно секции лучше всего располагать по выроненному адресу. Так более универсальнее. Для этого и стоит ALIGN().

Я понимаю, что это необходимость для ARM. Но для AVR я вижу только расход и так маленькой памяти без необходимости. Поэтому и поднял вопрос - или я чего-то не понимаю, и тогда мне объяснят и я стану умнее, или это просто недоработка и заходящие сюда авторы libc обратят на нее внимание.

Боюсь, что авторы binutils не смогут Вам ответить .

Не уверен. diwil имеет (имел?) к binutils отношение (правда в контексте mspgcc), кое-кто из участников имеет отношение к WinAVR и avr-libc (возможно, при работе с ней приходится и в binutils ковыряться), да и вообще - предполагаю, что многие участники используют gcc в различных видах и, возможно, знают точный ответ на мои глупые вопросы. А может кто-нибудь из спецов покачает головой вот так: и скажет: "Э... да это бага!" и тогда мы смело будем писать письмо турецкому султану (баг-репорт).

[amw]

Нет, уж лучше вы к нам

. Все может быть. Но я имел в виду потестить, а не полностью проект переписывать.

Я понимаю, что это необходимость для ARM. Но для AVR я вижу только расход и так маленькой памяти без необходимости. Поэтому и поднял вопрос - или я чего-то не понимаю, и тогда мне объяснят и я стану умнее, или это просто недоработка и заходящие сюда авторы libc обратят на нее внимание.

Я не в курсе AVR архитектуры, однако наводящий вопрос: могут ли быть какие нибудь команды (или ситуации), требующие четного адреса? Возможно. используя эти команды быстрее производится копирование блоков данных (типа копирование секции .data в ОЗУ). Ну или что-то в этом роде.

Не уверен. diwil имеет (имел?) к binutils отношение (правда в контексте mspgcc), кое-кто из участников имеет отношение к WinAVR и avr-libc (возможно, при работе с ней приходится и в binutils ковыряться), да и вообще - предполагаю, что многие участники используют gcc в различных видах и, возможно, знают точный ответ на мои глупые вопросы. А может кто-нибудь из спецов покачает головой вот так: и скажет: "Э... да это бага!" и тогда мы смело будем писать письмо турецкому султану (баг-репорт).

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

я имел в виду потестить, а не полностью проект переписывать.

Боюсь, что мне не удастся повторить этот эффект. Я в этом исходнике его с трудом "удержал" в процессе обрезания. Это я про предупреждение линкера. Про вывод секции в .hex - проверю.

Я не в курсе AVR архитектуры, однако наводящий вопрос: могут ли быть какие нибудь команды (или ситуации), требующие четного адреса?

В том-то и дело, что нет. 8-битный проц, все чисто байтовое. Точнее есть, но только одно место - заполнение буфера флеш при самопрограммировании производится по 2 байта. Но это никак с .data не связано.

К стати у меня на Debian Ваш пример компилится/линкуется без ошибок и варнингов.

Но "огрызок" секции .data с моим буфером все равно в хексе присутствует:

Код

:0200000400807A
:0600710000000000000089

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

amw, спасибо за толчок в новом направлении! Мысли упорядочиваются.

Поймал себя на логическом противоречии. Если мой буфер должен быть заполнен нулями (как и вся секция .bss), то его входная секция должна находиться между __bss_start = . и __bss_end = ., ведь по этим символам crt.s определяет обнуляемую область. Если же он не должен очищаться, то он и не должен находиться в выходной секции .bss. Значит ему место или в .noinit (проверил, эта секция появляется в хексе целиком и на варнинг это не влияет), но поскольку .noinit это скорее внешнее ОЗУ под батарейкой, то моему буферу место в отдельной выходной секции, про которую objcopy ничего заранее знать не может и, значит, про которую ему надо сообщать явно. Выходит, изначально ReAl был прав.

Теперь поймал на противоречии описание avr-libc. Там сказано, что .noinit является частью секции .bss, что противоречит и содержимому скриптов линкера из комплекта avr-libc и духу секции .bss (обнуленные при старте данные). Ведь в описании as ясно сказано:

4.5 bss Section
.....When your program starts running, all the contents of the bss section are zeroed bytes.

Кстати, вот где оно все должно было быть! avr-libc-user-manual:

9.3 Memory Sections
Remarks:
Need to list all the sections which are available to the avr.

Оно просто не дописано еще!

Тогда несколько изменил бы следующие два выражения оттуда:

9.3.2 The .data Section
This section contains static data which was defined in your code.
9.3.3 The .bss Section
Uninitialized global or static variables end up in the .bss section.

Все-таки uninitialized - это про .noinit. Я бы про .data написал This section contains static data which was explicitly initialized in your code. А про .bss: Global or static variables which are not explicitly initialized end up in the .bss section. Those variables are zeroed accordinary with C standart (ISO/IEC 9899:1999 6.7.8.10) И уже не поминал бы .bss в контексте .noinit.

И тут у меня появился следующий вопрос: почему в примерах WinAVR для получения .hex используется команда $(OBJCOPY) -R .eeprom , хотя более логичным было бы использование $(OBJCOPY) -j .text ? Ведь прошиваемой является только выходная секция .text! Рано радовался. Инициализирующие значения .data складываются после .text посредством : AT() в скрипте линкера. Надо подумать, нельзя ли их сложить внутрь .text, рядом с rodata - тогда бы все получилось красиво. А пока эти данные нельзя явно указать objcopy и приходится вместо этого указывать "все, кроме лишнего". И что-то из этого "лишнего" заботливо указано avr-objcopy авторами по-умолчанию (но вот в документации это не отражено или я не нашел). Остаются совсем маленькие вопросы - почему размер "обрезаемой" части .bss определяется по __bss_start и __bss_end, а не по размеру самой секции, ведь эта информация должна быть в объектном файле и objdump ее видит? И почему для avr-objcopy по-умолчанию не указана секция .init? На последнее могу предположить, что .noinit не бывает в больших процессорах, из которых выросли binutils, а список секций живет где-то в непортируемой части. Но это только предположение.

Итого, резюмируя, вопросов осталось три - откуда warning (таки баг сборщика мусора линкера?), почему в .data . = ALIGN(2) и почему в objcopy __bss_start/__bss_end.

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

И тут у меня появился следующий вопрос: почему в примерах WinAVR для получения .hex используется команда $(OBJCOPY) -R .eeprom , хотя более логичным было бы использование $(OBJCOPY) -j .text ? Ведь прошиваемой является только выходная секция .text! Рано радовался. Инициализирующие значения .data складываются после .text посредством : AT() в скрипте линкера. Надо подумать, нельзя ли их сложить внутрь .text, рядом с rodata - тогда бы все получилось красиво.

Развил мысль, все получилось. Надо objcopy указывать не только -j .text, но и -j .data Итого: $(OBJCOPY) -O ihex -j .text -j .data $< $@ копирует в хекс-файл только исполняемый код и инициализирующие значения для .data. Все остальное не копирует.

[singlskv]

Развил мысль, все получилось. Надо objcopy указывать не только -j .text, но и -j .data Итого: $(OBJCOPY) -O ihex -j .text -j .data $< $@ копирует в хекс-файл только исполняемый код и инициализирующие значения для .data. Все остальное не копирует.

ИМХО, этот вариант ничем не лучше того что я(и видимо Real) предлагал с удалением
секции -R buffer при производстве hex.

Основная проблемма скорее всего заключается в том, что сегмент определенный
в исходнике как:

Код

uint8_t Buffer[5] __attribute__((section("buffer"),used));

будет иметь все признаки секции .data , те его образ должен появлятся в выходном
hex файле, конечно если мы его "ручками"(-R) не выкинули.
Но при этом для таких секций не будет произведено преобразование адреса VMA в правильный
для сохранения в флеш адрес LMA, те либо это должно делаться в скрипте, либо пользуемся
опцией -R sectname

Покажите минимальный исходник+скрипт в котором есть проблема с лишними
данными в результируещем hex..., будем подумать...

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

ИМХО, этот вариант ничем не лучше того что я(и видимо Real) предлагал с удалением
секции -R buffer при производстве hex.

Мне он кажется "прямее", потому что надо явно указать что нужно (что я хочу) в выходном файле, а не указанием того, что мне не нужно.

Основная проблемма скорее всего заключается в том, что сегмент определенный
в исходнике как:

Код

uint8_t Buffer[5] __attribute__((section("buffer"),used));

будет иметь все признаки секции .data , те его образ должен появлятся в выходном
hex файле,

Откуда такой вывод? Если я его помещу в выходную секцию .data - появится, если в .bss - нет, и будет обнулен. Если в .noinit (или свою секцию) - и не появится и обнулен не будет.

Покажите минимальный исходник+скрипт в котором есть проблема с лишними данными в результируещем hex..., будем подумать...

Хорошо. Чуть позже.

[singlskv]

Мне он кажется "прямее", потому что надо явно указать что нужно (что я хочу) в выходном файле, а не указанием того, что мне не нужно.

Вот в этом мы и пытаемся разобраться... как "прямее"

Откуда такой вывод? Если я его помещу в выходную секцию .data - появится, если в .bss - нет, и будет обнулен. Если в .noinit (или свою секцию) - и не появится и обнулен не будет.

You may only use the section attribute with a fully initialized global definition
because of the way linkers work. The linker requires each object be defined once,
with the exception that uninitialized variables tentatively go in the common (or
bss) section and can be multiply “defined”. You can force a variable to be
initialized with the ‘-fno-common’ flag or the nocommon attribute.
это из описания gcc.pdf

то есть, ИМХО, по сути обявление своей секции данных, есть объявление алтернаивной
секции .data , но, для нее при этом, без доп телодвижений адрес LMA совпадает с адресом VMA,
и как следствие, мусор в hex тк эта секция не отмапилась на нужные нам адреса в флеш.

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

то есть, ИМХО, по сути обявление своей секции данных, есть объявление алтернаивной секции .data , но, для нее при этом, без доп телодвижений адрес LMA совпадает с адресом VMA, и как следствие, мусор в hex тк эта секция не отмапилась на нужные нам адреса в флеш.

Это я должен обдумать. Сейчас (пятница ) немного не могу въехать. Что-то мне казалось, что все у нас в руках - все секции можно описать в скрипте линкера. Надо указать LMA - указываем, не надо - будет совпадать с VMA. Куда хотим поместить - тот регион и указываем.

Прилагаю обещаный пример. Скрипт - стандартный avr4.x, только добавлена выходная секция .buffer в которую складывается входная buffer. В программе объявлен массив, помещаемый в buffer и массив, помещаемый в .noinit. в .data размещается переменная. По make all создаюся два хекса - Test1.hex создается по примеру WinAVR (objcopy -R .eeprom) - в нем появляются и .buffer и .noinit. Test2 создается по objcopy -j .text -j data - в нем только необходимые для прошивки .text и .data (по адресу LMA). В создаваемом из .elf дизассемблированном Test.lss видно, что все переменные размещаются в нужных адресах ОЗУ.

Извиняюсь, пропустил это письмо:

А .rodata? Константы нужны? В том числе и те, которые есть в компиляторах и библиотеках.

Конечно. Но они уже сложены в выходную секцию .text в скрипте линкера.

Не могу добиться варнинга.
А сравните версии компиляторов. (Я свою приводил выше). Может и в правду какая бага. У Вас есть, а у меня уже (или еще) нет.

avr-gcc.exe (GCC) 4.1.2 (WinAVR 20070525)
avr-gcc.exe (GCC) 3.4.6 (WinAVR 20060421)
avr-gcc.exe (GCC) 4.2.2 (WinAVR 20071221)
во всех трех случаях варнинг есть.

P.S. родилась еще одна безумная мысль - если у вас нет каких-то особых требований к расположению выходной секции .data в ОЗУ, то в ее начало можно поместить входные секции векторов в ОЗУ и .ramfunc, тогда они будут копироваться crt0.s из флеш в ОЗУ одним заходом вместе с .data

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

 Test2.ZIP ( 2.77 килобайт ) Кол-во скачиваний: 27

 

[amw]

Это я должен обдумать. Сейчас (пятница ) немного не могу въехать. Что-то мне казалось, что все у нас в руках - все секции можно описать в скрипте линкера. Надо указать LMA - указываем, не надо - будет совпадать с VMA. Куда хотим поместить - тот регион и указываем.

На третий день до жирафа дошло, что его ноги сбил паровоз .

А вот это не то что Вам надо?

Код

  .buffer (NOLOAD) :
  {
    *(buffer);
    KEEP (*(buffer))
  } > data

  .bss :
  {
     PROVIDE (__bss_start = .);
    *(.bss)
    *(.bss*)
    *(COMMON)
     PROVIDE (__bss_end = .);
  }  > data

Полный пример прилагается. Без -R и -j.

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

 sections.zip ( 9.25 килобайт ) Кол-во скачиваний: 32

 

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

секции .bss просто нет!
Вопрос, куда будут попадать переменные которые должны были бы быть в .bss ?

Ее нет, потому что в данном конкретном случае нет данных для нее. Когда есть - все размещается в те адреса, которые указаны для .bss в скрипте.

секция .buffer по сути(судя по ее атрибутам CONTENTS, ALLOC, LOAD, DATA)

А вот на эту строчку я никогда не обращал внимания, ибо не понимал ее содержание. Теперь все стало на свои места. Спасибо! Теперь понятно, почему objcopy -R .eeprom - потому что если скрипт написан правильно, то все, что кроме .eeprom должно идти во флеш.

А вот это не то что Вам надо?

А вот это именно оно! И решение лежит-то на поверхности... Видать меня ввело в заблуждение то, что (NOLOAD) в скриптах avr-libc не указан для .bss и .noinit. Спасибо! Вопрос можно считать закрытым.

P.S. WinAVR 20070525 (GNU ld version 2.17 + coff-avr-patch (20050630)) NOLOAD проигнорировал. WinAVR 20060421(GNU ld version 2.16.1 + coff-avr-patch (20050630)) и WinAVR 20071221(GNU ld (GNU Binutils) 2.18) отработали правильно.

[amw]

А вот это именно оно! И решение лежит-то на поверхности... Видать меня ввело в заблуждение то, что (NOLOAD) в скриптах avr-libc не указан для .bss и .noinit. Спасибо! Вопрос можно считать закрытым.

.bss по умолчанию (NOLOAD).

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

.bss по умолчанию (NOLOAD).

Теперь догадываюсь. Где про это можно прочитать?

[amw]

Теперь догадываюсь. Где про это можно прочитать?

Не помню точно.
Где-то в Binutils online documentation кажется.
Тут по GCC http://gcc.gnu.org/onlinedocs/
Тут по binutils http://sources.redhat.com/binutils/