avr-gcc, версия 4.1.1 вместо 3.3.1, Что-то изменилось в компиляторе, перестал нормально работать objdump, Опции

[impatt]

Решил обновить компилятор (версия 3.3.1, как мне кажется, в одном месте начала глючить, решил, что новый, вероятно, поведёт себя более правильно). Собирал из исходников, работаю в Linux.
Компилятор версии 4.1.1 рожает код (не проверял ещё, насколько он лучше и всё такое), но objdump версий 2.15 и 2.17 перестал везде правильно диззассемблировать рождённые объектники (может, дизассемблирование не совсем правильный термин):
если компилятор версии 3.1.1 практически на каждую строку С-шного текста позволял objdump-у выводить ассемблерный эксивалент строки, то новый позволяет местами: где-то всё по-старому, а где-то идёт массив ассемблерного кода, а С-шные строки сбиваются в кучу или вообще куда-то исчезают.
Кто-нибудь знает ,что происходит и как лечить ?
Примеры ниже.
Заранее благодарю за советы.

****************************************
К примеру, такая С-функция:
void putFString(uint8_t *stringPtr){
uint8_t temp;
while ((temp = pgm_read_byte_near(stringPtr)) != 0){
stringPtr++;
pushToDebugBuffer(temp);
};
return;
}
компилируется и команда 'avr-objdump -h -S ./uart.o' выводит следующее:
0000022c <putFString>:
22c: cf 93 push r28
22e: df 93 push r29
230: ec 01 movw r28, r24
232: 03 c0 rjmp .+6 ; 0x23a <putFString+0xe>
234: 21 96 adiw r28, 0x01 ; 1
236: 0e 94 00 00 call 0 ; 0x0 <nextAddress>
23a: fe 01 movw r30, r28
23c: 84 91 lpm r24, Z
23e: 88 23 and r24, r24
240: c9 f7 brne .-14 ; 0x234 <putFString+0x8>
242: df 91 pop r29
244: cf 91 pop r28
246: 08 95 ret

В то время, как компилятор версии 3.3.1 компилировал в объектники и 'avr-objdump -h -S ./uart.o' выводил листинг так:

00000000 <putFString>:

uint8_t f_hexPrefix[] PROGMEM ="0x";
uint8_t f_CR[] PROGMEM ="\n";

void putFString(uint8_t *stringPtr){
0: cf 93 push r28
2: df 93 push r29
4: ec 01 movw r28, r24
uint8_t temp;
while ((temp = pgm_read_byte_near(stringPtr)) != 0){
6: fc 01 movw r30, r24
8: 84 91 lpm r24, Z
a: 88 23 and r24, r24
c: 39 f0 breq .+14 ; 0x1c <putFString+0x1c>
stringPtr++;
e: 21 96 adiw r28, 0x01 ; 1
pushToDebugBuffer(temp);
10: 0e 94 00 00 call 0 ; 0x0 <putFString>
14: fe 01 movw r30, r28
16: 84 91 lpm r24, Z
18: 88 23 and r24, r24
1a: c9 f7 brne .-14 ; 0xe <putFString+0xe>
};
return;
}
1c: df 91 pop r29
1e: cf 91 pop r28
20: 08 95 ret

[Andy Great]

Оптимизация в компиляторе поменялась, наверное?

[klen]

Оптимизация в компиляторе поменялась, наверное?

Поставте в опциях компиляции -O0 и сравните. Проверьте наличие ключа компиляции -dwarf-2, имено по ней в обектник складывается отладочная информация. Хотя у меня с -Os все выводит нормально, пользуюсь gсс4.2.0+bu2.17

[impatt]

Оптимизация в компиляторе поменялась, наверное?

Поставте в опциях компиляции -O0 и сравните. Проверьте наличие ключа компиляции -dwarf-2, имено по ней в обектник складывается отладочная информация. Хотя у меня с -Os все выводит нормально, пользуюсь gсс4.2.0+bu2.17

Проверил -O0. Та-же фигня.
-gdwarf-2 стандартными binutils не поддерживается, надо либо в параметрах configure при сборке им сказать, либо специальный патч накатить... Как вы делали ?
Впрочем, те binutils, что под avr-gcc-3.3.1 работают, тоже стандартные, без лишних патчей, поддержки dwarf-2 и так далее - нормально. Видимо, дело в компиляторе ?

Сообщение отредактировал impatt - Oct 23 2006, 08:46

[aesok]

-gdwarf-2 стандартными binutils не поддерживается, надо либо в параметрах configure при сборке им сказать, либо специальный патч накатить... Как вы делали ?

Да и GCC, и binutils надо сказать про поддержку dwarf2. Вот параметры для binutils.

configure -v --target=avr --prefix=..... --with-gnu-ld --with-gnu-as --quiet --enable-install-libbfd --with-dwarf2

Анатолий.

[impatt]

-gdwarf-2 стандартными binutils не поддерживается, надо либо в параметрах configure при сборке им сказать, либо специальный патч накатить... Как вы делали ?

Да и GCC, и binutils надо сказать про поддержку dwarf2. Вот параметры для binutils.

configure -v --target=avr --prefix=..... --with-gnu-ld --with-gnu-as --quiet --enable-install-libbfd --with-dwarf2

Счас попробую и запишу на будущее.
Вообще-то, подобные пересборки для меня редки и откуда выковыривать все волшебные опции (кроме как из configure --help и редкостречающихся инструкций по сборке) - не знаю. Наверное, есть тайное сообщество посвящённых , которые знают все опции и рассказывают о них только когда спросят

>> -gdwarf-2 стандартными binutils не поддерживается....
это чтото новенькое для меня. что за "стандартные bu"???, может компилятор был собран без --with-dwarf2. Eсли есть желание возьмите скачайте мою сборку, все кто пользуется довольны.

Ну, я прошу прощения. Стандартные - это не то слово. Скажем так, я имел в виду тот случай, когда используются опции configure, взятые из configure --help
Скачивать не стану, но за предложение - спасибо. Сам пособираю, так интеерснее
Компилятор собран без -dwarf-2, ессно (так что если он не конфигурируется сам по умолчанию, то удивляться отсусствию поддержки dwarf2 не следует

Сообщение отредактировал impatt - Oct 23 2006, 10:02

[klen]

..... и откуда выковыривать все волшебные опции (кроме как из configure --help и редкостречающихся инструкций по сборке) - не знаю. Наверное, есть тайное сообщество посвящённых , которые знают все опции и рассказывают о них только когда спросят

о-о-о--о.... .. это супертайное и сверхсекретное общество .. и как оно живет никто не видит.. потому что GCC можно собрать тоько ночьюю !!! при свете костра и бубна. днем члены общества косят под обычных программистов. Чтоб вступить в общество нада долго-долго-долго компилировать gcc ночью - потом открывается пятый глаз который будет видеть все опции командной строки при первом взгляде.

Без шуток. собрать под линухом просто, собрать под CygWin сложнее(временами шаманство). собрать под MinGW - перманентное шаманство с бубном, четками и жеским рукопрекладством к скриптам и макефайлам. Пример - сегодня ноччу спытался собрать свежий снимок 4.2.0 c поможу 4.1.1 для самой MinGW , вобщем все зациклилось на сборке стадии "сам себя", после 6 пересборки я понял что чтото пошло не так плюнул и лег спать. Вот так.

[impatt]

о-о-о--о.... .. это супертайное и сверхсекретное общество
собрать под линухом просто,

Да, под линуксом несложно. Но всё же: откуда взять хотя бы полный перечень возможных опций configure ? Если будет перечень, то можно погуглить и узнать о них. Уверен, там найдётся что-то полезное, что мне (и не только мне) нужно.

[andrew_b]

Но всё же:откуда взять хотя бы полный перечень возможных опций configure ?

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

[impatt]

Но всё же:откуда взять хотя бы полный перечень возможных опций configure ?

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

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

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

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

Код

checking for avr-gcc... /usr/src/gcc-obj/./gcc/xgcc -B/usr/src/gcc-obj/./gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include  -mmcu=avr3
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libssp] Ошибка 1

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

[aesok]

Ошибка такая:

Код

checking for avr-gcc... /usr/src/gcc-obj/./gcc/xgcc -B/usr/src/gcc-obj/./gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include  -mmcu=avr3
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libssp] Ошибка 1

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

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

Анатолий.

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

[impatt]

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

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

Код

../gcc-4.1.1/configure -v --target=avr --quiet --enable-languages=c --without-libssp

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

[aesok]

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

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

Код

../gcc-4.1.1/configure -v --target=avr --quiet --enable-languages=c --without-libssp

Ошибка та самая, про которую писал в прошлом посте.

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

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

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

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

Анатолий.

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

[impatt]

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

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

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

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

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

[aesok]

Правда, всё таки, 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 формате?

Анатолий.

[impatt]

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

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

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

Не генерируеться отладочная информация для вашего кода или для библиотечных функций? Большая часть 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)

Код

00003082 <pushToDebugBuffer>:

uint8_t pushToDebugBuffer(uint8_t symbol){
    3082:       cf 93           push    r28
    3084:       c8 2f           mov     r28, r24
        DEBUG_TX_INT_LOCK();
    3086:       56 98           cbi     0x0a, 6; 10
        while(debugPushCursor == debugPopCursor){
    3088:       20 91 00 03     lds     r18, 0x0300
    308c:       30 91 01 03     lds     r19, 0x0301
    3090:       80 91 fe 02     lds     r24, 0x02FE
    3094:       90 91 ff 02     lds     r25, 0x02FF
    3098:       28 17           cp      r18, r24
    309a:       39 07           cpc     r19, r25
    309c:       71 f4           brne    .+28           ; 0x30ba
                DEBUG_TX_INT_UNLOCK();
    309e:       56 9a           sbi     0x0a, 6; 10
                SLEEP();
    30a0:       88 95           sleep
                DEBUG_TX_INT_LOCK();
    30a2:       56 98           cbi     0x0a, 6; 10
    30a4:       20 91 00 03     lds     r18, 0x0300
    30a8:       30 91 01 03     lds     r19, 0x0301
    30ac:       80 91 fe 02     lds     r24, 0x02FE
    30b0:       90 91 ff 02     lds     r25, 0x02FF
    30b4:       28 17           cp      r18, r24
    30b6:       39 07           cpc     r19, r25
    30b8:       91 f3           breq    .-28           ; 0x309e
        }
        *debugPushCursor = symbol;
    30ba:       e0 91 00 03     lds     r30, 0x0300
    30be:       f0 91 01 03     lds     r31, 0x0301
    30c2:       c0 83           st      Z, r28
        debugPushCursor = nextAddress(debugPushCursor);
    30c4:       80 91 00 03     lds     r24, 0x0300
    30c8:       90 91 01 03     lds     r25, 0x0301
    30cc:       0e 94 9f 18     call    0x313e
    30d0:       90 93 01 03     sts     0x0301, r25
    30d4:       80 93 00 03     sts     0x0300, r24
        DEBUG_TX_INT_UNLOCK();
    30d8:       56 9a           sbi     0x0a, 6; 10
        if(!globIntFlags.isDebugPortBusy) popFromDebugBuffer(); //если передача когда-то закончилась, то возобновляем её
    30da:       80 91 aa 01     lds     r24, 0x01AA
    30de:       88 1f           adc     r24, r24
    30e0:       88 27           eor     r24, r24
    30e2:       88 1f           adc     r24, r24
    30e4:       99 27           eor     r25, r25
    30e6:       89 2b           or      r24, r25
    30e8:       11 f4           brne    .+4            ; 0x30ee
    30ea:       0e 94 7b 18     call    0x30f6
        return symbol;
    30ee:       8c 2f           mov     r24, r28
    30f0:       99 27           eor     r25, r25
}
    30f2:       cf 91           pop     r28
    30f4:       08 95           ret

Пример на версии 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)

Код

000030cc <pushToDebugBuffer>:
    30cc:       1f 93           push    r17
    30ce:       18 2f           mov     r17, r24
    30d0:       02 c0           rjmp    .+4            ; 0x30d6 <pushToDebugBuffer+0xa>
    30d2:       56 9a           sbi     0x0a, 6; 10
    30d4:       88 95           sleep
    30d6:       56 98           cbi     0x0a, 6; 10
    30d8:       20 91 00 03     lds     r18, 0x0300
    30dc:       30 91 01 03     lds     r19, 0x0301
    30e0:       80 91 fe 02     lds     r24, 0x02FE
    30e4:       90 91 ff 02     lds     r25, 0x02FF
    30e8:       28 17           cp      r18, r24
    30ea:       39 07           cpc     r19, r25
    30ec:       91 f3           breq    .-28           ; 0x30d2 <pushToDebugBuffer+0x6>
    30ee:       e0 91 00 03     lds     r30, 0x0300
    30f2:       f0 91 01 03     lds     r31, 0x0301
    30f6:       10 83           st      Z, r17
    30f8:       80 91 00 03     lds     r24, 0x0300
    30fc:       90 91 01 03     lds     r25, 0x0301
    3100:       01 96           adiw    r24, 0x01      ; 1
    3102:       22 e0           ldi     r18, 0x02      ; 2
    3104:       8e 3f           cpi     r24, 0xFE      ; 254
    3106:       92 07           cpc     r25, r18
    3108:       11 f4           brne    .+4            ; 0x310e <pushToDebugBuffer+0x42>
    310a:       8e e7           ldi     r24, 0x7E      ; 126
    310c:       92 e0           ldi     r25, 0x02      ; 2
    310e:       90 93 01 03     sts     0x0301, r25
    3112:       80 93 00 03     sts     0x0300, r24
    3116:       56 9a           sbi     0x0a, 6; 10
    3118:       80 91 aa 01     lds     r24, 0x01AA
    311c:       87 fd           sbrc    r24, 7
    311e:       02 c0           rjmp    .+4            ; 0x3124 <pushToDebugBuffer+0x58>
    3120:       0e 94 3d 18     call    0x307a ; 0x307a <popFromDebugBuffer>
    3124:       81 2f           mov     r24, r17
    3126:       99 27           eor     r25, r25
    3128:       1f 91           pop     r17
    312a:       08 95           ret

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

[aesok]

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

Анатолий.

[impatt]

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

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