У каждой программы есть свои специфические опции. Узнать их можно, посмотрев внутрь файла configure.ac (или configure.in). Это сценарий autoconf, которыйи генерирует configure. В общем, пытайте Гугл на тему GNU Autotools.

Интересно. Действительно, не для средних умов.
Достаточно ли патча patch-dwarf для того,чтобы накатить его на gcc-4.1.1 и скомпилить с поддержкой dwarf-2 ?
А то теперь не получается никак скомпилировать.

Какие ошибки?

Как минимум ставте патчи patch-newdevices и patch-dwarf.

Анатолий.

Ну, что-ж, уже хорошо А то просто непонятно, где что есть.
Спасибо


Поставил оба.
Ошибка такая:


Меня не оставляет ощущение, что я не полностью предоставляю информацию об обшибках компиляции. Но каждый раз прикреплять логи конфига, всего-всего как-то избуточно, а как отобрать нужное - только догадываюсь. Так что если что - поправляйте.

Отлично!!! Так все и дожно быть!!! Добавте "--disable-libssp" при конфигурации GCC.

Анатолий.

Сообщение отредактировал aesok - Oct 24 2006, 10:39

Собственно, так и делал:


Ошибка та самая, про которую писал в прошлом посте.
Кстати, мож, пропатчил просто плохо ?
Я сперва накатил (кажется патч patch-dwarf, затем patch-newdevices, причём ввиду того, что опыта с командой patch немного, то просто поместил оба патча в корень исходников gcc и находясь там-же, сделал patch -p1 <./patch*. Команда patch не захотела найти файлы, подлежащие правке, но написала, мол, файл такой-то предписано патчить, но найти его не могу. Ну, набирал имена вручную и всё такое.
Может, следует делать иначе ?

"--disable-XXX" и "--without-XXX" не взаимозаменяемы. Нужно всетаки "--disable-libssp".



Нет эта ошибка никак не связана с этими патчами. Это ошибка при компиляции Stack Smash Protection библиотеки (Защита от разрушения стека). На AVR вещь совершенно бесполезная.

Вот маленькая статья, правда на английском, в ней основное что нужно знать про diff и patch:
http://www.network-theory.co.uk/articles/patchintro.html

Анатолий.

Сообщение отредактировал aesok - Oct 25 2006, 06:30

Да, это верно. Попутал.


Спасибо. Статейку гляну.
В общем, собралось и работает. Спасибо за помощь
Правда, всё таки, avr-gcc-4.1.1, поддержкой dwarf-2, вкупе с "avr-objdump -S -h" генерит по прежнему не очень хорошие листинги по сравнению с avr-gcc-3.3.1. С-шный текст куда-то теряется (не везде), и видны здоровые массивы ассемблера. Мож, есть другие причины, например, в gcc-4.* что-то поменяли капитально ?
Впрочем, я уже понял, что эти проблемы ничто, по сравнению с мировой революцией

Пожалуйста задавайте вопросы по человечески, как инженер!!!

Что значит "не очень хорошие листинги", что значит "текст куда-то теряется (не везде)", ГДЕ??????

Не генерируеться отладочная информация для вашего кода или для библиотечных функций? Большая часть avr-libc написана на ассемблере. Вы используете avr-libc которая скомпилирована с помощю GCC 3.1, тоесть без отладочно й информации в dwarf-2 формате. Когда вы компилируете свой код, вы указали компилятору что вам нужна отладочная информация в dwarf-2 формате?

Анатолий.

Я стараюсь найти компромисс между большим объёмом подробностей, которые будут затмевать весь смысл поста, и его краткостью-и-привлекательностью. Разумеется, мне не всегда просто догадаться, что может потребоваться знать человеку, который возмётся разобраться с вопросом, а ещё иногда просто что-то о своей проблеме знаю и теряю из вида то, что все остальные не знают.


Ну, вот теперь примерно ясно, что было понято из сказаного мной, и сейчас уточняю:
Как и писал в самом начале топика, и уточняю сейчас, компилятор версии 4.1.1, в отличии от версии 3.3.1, генерит такие объектники, что после обработки objdump получается, что местами вместо строк С, перемежённых сгенерированными компилятором ассемблерными строками, получаются массивы ассемблера, а соответствющий код С сбивается в кучи в других местах. Всё это относится к коду на С, который я пишу сам.

Компилятор вызывается строками типа такой: $(CC) $(CFLAGS) -c -o tables.o $(SRCDIR)/dataconvert/tables.c
CC == avr-gcc (разумеется)

Пример на компиляторе 3.3.1, (CFLAGS такая: -mmcu=atmega128 -Os -g3 -DCALIBR_ENABLE_REAL_COEF_STORE -DCALIBTABLE_EEPROM -DAVRPART -DADCPART=ADS1243 -DPCBVER=0311 -I . -I /usr/local/avr/include -Wall)



Пример на версии 4.1.1, та-же самая строка вызова компилятора, добавлено -gdwarf-2 (CFLAGS такая: -gdwarf-2 -mmcu=atmega128 -Os -g3 -DCALIBR_ENABLE_REAL_COEF_STORE -DCALIBTABLE_EEPROM -DAVRPART -DADCPART=ADS1243 -DPCBVER=0311 -I . -I /usr/local/avr/include -Wall)



С-шный код в этом случае потерялся вовсе, но так не всегда: иногда он, как и было сказано ранее, сиротливо лежит в уголке листинга так-же, как он есть в исходном файле.

Проверте версию "avr-objdump", возможно вы пытаетесь посмотреть отладочную версию в формате dwarf-2, а используемая версия avr-objdump про него не знает. Что показывает "avr-objdump --version"? Точно 2.17? Tокда попробуйте еще раз сконфигурировать/создать binutils с поддежкой dwarf-2.

Анатолий.

Проверил, сконфигурил, собрал, установил и снова проверил - всё по старому.
Может, сперва удалить надо всё, что ручками накомпилено было ? Правда, в случае с gcc и binutils я не знаю, как сделать, ибо make uninstall не работает.
А как, кстати, деинсталлировать gcc и binutils ?
И ещё: у вас нет таких проблем ? Листинги чётко получаются ?

Странненько. Вообще проблем нет.

Давайте так, напишите полностю:
1. опции конфигурации binutils
2. опции конфигурации gcc
после этого Вы собрали все
3. опции компиляции
4. опции линкера
5. опции avr-objdump

Дальше будем думать

У меня к примеру так собирается прошивка

Это хорошо. Во первых, тем, что у кого-то всё таки оно работает, а во вторых тем, что есть шанс, что заработает и у меня


На момент начала экспериментов у меня в недрах компа валялась (и валяется по сию пору по причине того, что не могу заняться вплотную удалением) версия avr-gcc-4.0.2, которой особо не пользовался, и avr-binutils-2.15 (тоже по причине трудностей с удалением). Может ли наличие этих вещей мешать ?
Ну, теперь об опциях и способах конфигурирования и компиляции. Сперва я собирал binutils-2.17 и gcc-4.1.1 без dwarf-2 (мне, по идее, не очень пока важно, какая там тема с отладочной информацией, пока что stabs, что dwarf-2 - всё едино). Затем увидел проблемы с листингом и начал спрашивать тут. После этого я пытался скомпилировать gcc с поддержкой dwarf-2, для чего накатил два патча (см. выше по теме). Которые накатились. Собрал снова gcc-4.1.1 и потом, уже сегодня, binutils-2.17. Допускаю, что такой "порядок" сборки мог вызвать некие аномалии в сборке и конфигурировании обоих продуктов. Как уже сказал, удалить то, что уже собрано я не знаю как.
Компиляцию и конфигурирование проводил в отдельных от исходников папках (вроде, так написано в доке на gcc было пару лет назад, больше не проверял, продолжаю действовать согласно этим сведениям).
Теперь про опции:
1. binutils-2.17
1.1. конфигурирование: ../binutils-2.17/configure -v --target=avr --with-gnu-ld --with-gnu-as --quiet --enable-install-libbfd --with-dwarf2
1.2. компилирование: make -j2
1.3. установка: make install
2. gcc
2.1. конфигугрирование: ../gcc-4.1.1/configure -v --target=avr --quiet --enable-languages=c --disable-libssp --with-dwarf2
2.2. компилирование: make -j2
2.3. установка: make install

Компилирование моих объектников, как и было сказано выше в этой ветке, делается так:
avr-gcc -gdwarf-2 -mmcu=atmega128 -Os -g3 -I . -I /usr/local/avr/include -Wall -o file.o file.c

Линкер (пишу, как вызывается линкер самим gcc, ничего не меняя): /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/ld -m avr5 -Tdata 0x800100 -o bootstrap.elf /usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib/crtm128.o -L/usr/local/lib/gcc/avr/4.1.1/avr5 -L/usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib/avr5 main.o spi.o in2out.o ads1243.o error.o tables.o modbus.o interrupt.o ifADC.o misc.o memory.o uart.o -lm -lgcc -lc -lgcc

Objdump: avr-objdump -h -S ./bootstrap.elf >./bootstrap.lst


Для меня сложны некоторые вещи (передача незнакомых мне параметров ассемблеру и прочее), потому мне несколько затруднительно оценить всю мощь Ваших конструкций
Если Вас не затруднит, гляньте в мои изыскания, может, я там просто где-то недоглядел ?
Спасибо

Пока короткий ответ.

Увидел я про что вы говорите!!! Если объектный файл маленький то листинг правильный, если большой то гдето после килобайта кода (у меня с адреса 0x52e), как вы и писали, кусок кода на С, потом чистый ассеблерный код. (GCC 4.2/binutils 2.17).

Если у вас есть время пожалуста посмотрите что получаеться с отладочной информацией stabs, с без оптимизации (-O0).

> пока что stabs, что dwarf-2 - всё едино

В GDB не полностью поддерживает dwarf-2 - ему нужна stabs, AVRStudio работает с dwarf-2 и coff.

Анатолий.