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

ОК. Убедили, но проверте все же как именно выполняется копирование. Выравние из ниоткуда?

Должны же быть причины для такого выравнивания.

Нормально выполняется. Вот я и надеюсь, что aesok прояснит этот вопрос.

Да. Но! В любом случае, эта часть (копирование и обнуление секций) не есть часть компилятора.

В embedded-мире - это часть libc.

Да, согласен.

 

Ага. А где гарантия, что за секция .data (LMA) идет после секции .text? Простейший пример:

Что делает Ричи Блэкмор, когда берет неправильную ноту?

- Вау! Еще и так можно!

:) Вот уж не знал, что выходные секции можно разбивать на части и тасовать. Но в таком случае было бы логично выравнивать начало .text, а не конец предыдущей .data. В общем, пока получается гадание на кофейной гуще.

 

А вот родилась мысль - может они хотели сделать быстрое копирование, копируя по два байта за каждый проход цикла? Или может так оно и было когда-то, но потом отказались, а это выравнивание - рудимент?

[amw 0]

Нормально выполняется. Вот я и надеюсь, что aesok прояснит этот вопрос.Да, согласен.

 

:) Вот уж не знал, что выходные секции можно разбивать на части и тасовать. Но в таком случае было бы логично выравнивать начало .text, а не конец предыдущей .data. В общем, пока получается гадание на кофейной гуще.

Это был простейший пример.

За секцией .data следуют другие секции, и они могут то-же требовать выравнивания. В общем случае, разумеется. Логично выравнивать каждую секцию, размер которой может быть не кратным.

А вот родилась мысль - может они хотели сделать быстрое копирование, копируя по два байта за каждый проход цикла? Или может так оно и было когда-то, но потом отказались, а это выравнивание - рудимент?

Может и так быть. Однако следует осторожно к этому подходить. И ждать специалиста по binutils :).

И еще вариант.

Пишем скрипт для одного процессора. Потом появляется новый. Копируем старый скрипт, добавляем нужное (например выравнивание). Потом появляется еще один процессор. Копируем уже модифицированный скрипт и вносим изменения для третьего процессора и т.д.

[singlskv 0]

Развил мысль, все получилось. Надо 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..., будем подумать...

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

ИМХО, этот вариант ничем не лучше того что я(и видимо Real) предлагал с удалением

секции -R buffer при производстве hex.

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

 

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

в исходнике как:

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

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

hex файле,

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

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

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

[singlskv 0]

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

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

Откуда такой вывод? Если я его помещу в выходную секцию .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 тк эта секция не отмапилась на нужные нам адреса в флеш.

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

то есть, ИМХО, по сути обявление своей секции данных, есть объявление алтернаивной секции .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

[amw 0]

Конечно. Но они уже сложены в выходную секцию .text в скрипте линкера.avr-gcc.exe (GCC) 4.1.2

Точнее у Вас в .data.

У меня (ARM) отдельная секция для .rodata, и ее не надо копировать в озу.

(WinAVR 20070525)

avr-gcc.exe (GCC) 3.4.6 (WinAVR 20060421)

avr-gcc.exe (GCC) 4.2.2 (WinAVR 20071221)

во всех трех случаях варнинг есть.

avr-gcc (GCC) 4.1.0 (Debian/amd64)

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

Это Вы про мой пример?

Мысль не безумная, а вполне здравая.

Однако есть причины.

[singlskv 0]

Это я должен обдумать. Сейчас (пятница :) ) немного не могу въехать.

Таки пятница... и Ваш пример сразу не собрался,

собственно интересно что показывает "avr-objdump -h projname.elf"

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

Точнее у Вас в .data.

Да, с .rel.rodata попутал.

У меня (ARM) отдельная секция для .rodata, и ее не надо копировать в озу.

Да, точно. Опять же это распределяется распихиванием входных секций по соответствующим выходным (секциям, а не дням :) ).

 

Таки пятница... и Ваш пример сразу не собрался,

собственно интересно что показывает "avr-objdump -h projname.elf"

Test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000074  00000000  00000000  000000b4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .buffer       00000005  00800060  00800060  00000129  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .data         00000001  00800065  00000074  00000128  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .noinit       00000005  00800066  00800066  0000012e  2**0
                  ALLOC
  4 .stab         00000378  00000000  00000000  00000130  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .stabstr      00000071  00000000  00000000  000004a8  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_aranges 00000028  00000000  00000000  00000519  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_pubnames 00000038  00000000  00000000  00000541  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   0000011d  00000000  00000000  00000579  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 00000099  00000000  00000000  00000696  2**0
                  CONTENTS, READONLY, DEBUGGING
10 .debug_line   00000127  00000000  00000000  0000072f  2**0
                  CONTENTS, READONLY, DEBUGGING
11 .debug_frame  00000020  00000000  00000000  00000858  2**2
                  CONTENTS, READONLY, DEBUGGING
12 .debug_str    000000b1  00000000  00000000  00000878  2**0
                  CONTENTS, READONLY, DEBUGGING

Все как и задумано.

[singlskv 0]

Test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000074  00000000  00000000  000000b4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .buffer       00000005  00800060  00800060  00000129  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .data         00000001  00800065  00000074  00000128  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .noinit       00000005  00800066  00800066  0000012e  2**0
                  ALLOC
  4 .stab         00000378  00000000  00000000  00000130  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .stabstr      00000071  00000000  00000000  000004a8  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_aranges 00000028  00000000  00000000  00000519  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_pubnames 00000038  00000000  00000000  00000541  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   0000011d  00000000  00000000  00000579  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 00000099  00000000  00000000  00000696  2**0
                  CONTENTS, READONLY, DEBUGGING
10 .debug_line   00000127  00000000  00000000  0000072f  2**0
                  CONTENTS, READONLY, DEBUGGING
11 .debug_frame  00000020  00000000  00000000  00000858  2**2
                  CONTENTS, READONLY, DEBUGGING
12 .debug_str    000000b1  00000000  00000000  00000878  2**0
                  CONTENTS, READONLY, DEBUGGING

Все как и задумано.

не понимаю что Вы имеете в виду говоря "как и задуманно"

секции .bss просто нет!

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

вторая секция .data , те будет прописанна в флеш

 

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

 

ну и LMA у .buffer указывает на 00800060, те при генерации hex гарантированно будет "мусор"...

[amw 0]

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

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

 

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

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

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

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

sections.zip

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

секции .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 0]

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

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

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

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

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

[amw 0]

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

Не помню точно. :(

Где-то в Binutils online documentation кажется.

Тут по GCC http://gcc.gnu.org/onlinedocs/

Тут по binutils http://sources.redhat.com/binutils/