Сергей Борщ 134 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба ОК. Убедили, но проверте все же как именно выполняется копирование. Выравние из ниоткуда? Должны же быть причины для такого выравнивания. Нормально выполняется. Вот я и надеюсь, что aesok прояснит этот вопрос.Да. Но! В любом случае, эта часть (копирование и обнуление секций) не есть часть компилятора. В embedded-мире - это часть libc. Да, согласен. Ага. А где гарантия, что за секция .data (LMA) идет после секции .text? Простейший пример: Что делает Ричи Блэкмор, когда берет неправильную ноту? - Вау! Еще и так можно! :) Вот уж не знал, что выходные секции можно разбивать на части и тасовать. Но в таком случае было бы логично выравнивать начало .text, а не конец предыдущей .data. В общем, пока получается гадание на кофейной гуще. А вот родилась мысль - может они хотели сделать быстрое копирование, копируя по два байта за каждый проход цикла? Или может так оно и было когда-то, но потом отказались, а это выравнивание - рудимент? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amw 0 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Нормально выполняется. Вот я и надеюсь, что aesok прояснит этот вопрос.Да, согласен. :) Вот уж не знал, что выходные секции можно разбивать на части и тасовать. Но в таком случае было бы логично выравнивать начало .text, а не конец предыдущей .data. В общем, пока получается гадание на кофейной гуще. Это был простейший пример. За секцией .data следуют другие секции, и они могут то-же требовать выравнивания. В общем случае, разумеется. Логично выравнивать каждую секцию, размер которой может быть не кратным. А вот родилась мысль - может они хотели сделать быстрое копирование, копируя по два байта за каждый проход цикла? Или может так оно и было когда-то, но потом отказались, а это выравнивание - рудимент? Может и так быть. Однако следует осторожно к этому подходить. И ждать специалиста по binutils :). И еще вариант. Пишем скрипт для одного процессора. Потом появляется новый. Копируем старый скрипт, добавляем нужное (например выравнивание). Потом появляется еще один процессор. Копируем уже модифицированный скрипт и вносим изменения для третьего процессора и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Развил мысль, все получилось. Надо 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..., будем подумать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба ИМХО, этот вариант ничем не лучше того что я(и видимо Real) предлагал с удалением секции -R buffer при производстве hex. Мне он кажется "прямее", потому что надо явно указать что нужно (что я хочу) в выходном файле, а не указанием того, что мне не нужно. Основная проблемма скорее всего заключается в том, что сегмент определенный в исходнике как: uint8_t Buffer[5] __attribute__((section("buffer"),used)); будет иметь все признаки секции .data , те его образ должен появлятся в выходном hex файле, Откуда такой вывод? Если я его помещу в выходную секцию .data - появится, если в .bss - нет, и будет обнулен. Если в .noinit (или свою секцию) - и не появится и обнулен не будет. Покажите минимальный исходник+скрипт в котором есть проблема с лишними данными в результируещем hex..., будем подумать...Хорошо. Чуть позже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Мне он кажется "прямее", потому что надо явно указать что нужно (что я хочу) в выходном файле, а не указанием того, что мне не нужно.Вот в этом мы и пытаемся разобраться... :) как "прямее" Откуда такой вывод? Если я его помещу в выходную секцию .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 тк эта секция не отмапилась на нужные нам адреса в флеш. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба то есть, ИМХО, по сути обявление своей секции данных, есть объявление алтернаивной секции .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 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Конечно. Но они уже сложены в выходную секцию .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 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Это я должен обдумать. Сейчас (пятница :) ) немного не могу въехать. Таки пятница... и Ваш пример сразу не собрался, собственно интересно что показывает "avr-objdump -h projname.elf" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба Точнее у Вас в .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 14 марта, 2008 Опубликовано 14 марта, 2008 · Жалоба 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 15 марта, 2008 Опубликовано 15 марта, 2008 · Жалоба Это я должен обдумать. Сейчас (пятница :) ) немного не могу въехать. Что-то мне казалось, что все у нас в руках - все секции можно описать в скрипте линкера. Надо указать 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 15 марта, 2008 Опубликовано 15 марта, 2008 · Жалоба секции .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 15 марта, 2008 Опубликовано 15 марта, 2008 · Жалоба А вот это именно оно! И решение лежит-то на поверхности... Видать меня ввело в заблуждение то, что (NOLOAD) в скриптах avr-libc не указан для .bss и .noinit. Спасибо! Вопрос можно считать закрытым. .bss по умолчанию (NOLOAD). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 15 марта, 2008 Опубликовано 15 марта, 2008 · Жалоба .bss по умолчанию (NOLOAD).Теперь догадываюсь. Где про это можно прочитать? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amw 0 15 марта, 2008 Опубликовано 15 марта, 2008 · Жалоба Теперь догадываюсь. Где про это можно прочитать? ;) Не помню точно. :( Где-то в Binutils online documentation кажется. Тут по GCC http://gcc.gnu.org/onlinedocs/ Тут по binutils http://sources.redhat.com/binutils/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться