Что касается особенностей работы GNU-программ, читайте общие описания - АВРовские тулзы наследуют общую функциональность.

Всем! Всем! Всем!
Действительно глюк компилятора точнее линковщика avr-ld.
В интернете по этому поводу ничего вразумительного, и все проекты в инете имеют минимальный код чтоб обходится без JMP и CALL, используют только RJMP и RCALL , и всегда выбирают как правило AT90S8515. На двух сайтах людьми на форумах была поднята эта тема OPCODE JMP,CALL для WINAVR, никто не ответил ничего.

А глюк выдал себя вот так: как я говорил, если непосредственно записать числовое значение в эти команды, то OPCODE правильный. Если ставить текстовую метку в качестве адреса перехода на команду JMP, начинается проблема с генерированием OPCODE (хотя на командах RJMP и RCALL такое безобразие не проявляется(в этом и суть)).
Выявлял проблему так: разместил команду Start: JMP Start на нулевой адрес, OPCODE = 940C000 - правильный OPCODE. Далее поменял параметр JMP START+4, скомпилировал, получил OPCODE = 94100000 -уже неправильный OPCODE (правильный 940C0002). Далее еще увеличил параметр JMP START+4, получил также неправильный OPCODE 94140000 (правильный 940C0004).
Дальше еще лучше, короче глюченный линковщик и на этом точка. Я же немогу применять команды JMP при самостоятельных высчитах смещения адресов.

Но все-таки хорошее от WINAVR есть. Исправно генерит с "C" файла текстовый ассемблерный файл. Правда этот файл надо подредактировать, чтобы скормить ассемблеру в AVR STUDIO. Этим далее я и буду заниматься позже - напишу утилиту переработки ассемблерного текста с avr-as на вид воспринимаемый ассемблером из AVRSTUDIO.

Вот такие пироги.

скажу сразу что с вопросом не разбирался... просто хочу подкинуть пару мыслей перед тем как вы окончательно уличили линковщик...

Картошка: а вы зачем дизассемблируете ОБЬЕКТНИК? обьектный файл не содержит ОКОНЧАТЕЛЬНОГО кода. по идеологии обьектного файла адреса внешних функций ДО линковки (т.е. на стадии обьектного файла) НЕИЗВЕСТНЫ. известны лишь символьные имена меток. а для того, что бы вызывались конкретные адреса (а не текстовые строки) в коде могут оставляться опкоды "пустышки", которые на стадии линковки дополняются. можно "запудрить" линковщик до такой степени, что он так и оставит эти "пустышки" в конечном коде, но если делать как общепринято, такого не случится.

Спасибо "Petka" . Я уже все перепробовал : и обьектник дизассемблировал, чтоб хоть убедится что ни он портачит. Мои мысленные допуски по поводу нулевых адресов на командах JMP и CALL в обьектном модуле подтвердились, ведь это дело линковщика адресса расставлять. Но проблема не в том, что линковщик их не расставляет, а в том что он их расставляет с искажением OPCODE. Попробуйте написать маленькую програмку, а потом залинковать. Примеры скрипта в этом разделе темы, наверху.

Я этот же вопрос задал на AVRFREAKS , может действительно проблема, или будут смеятся.

Вчера написал утилиту автоматической шлифовки ассемблерного, листинга c avr-gcc -S на удобовоспринимаемый ассемблером из AVR STUDIO с которым я уже долго работаю. Из WINAVRа буду использовать только avr-gcc с опцией -S для выдачи ассемблерного файла и все (линковать не прийдется ) . А ассемблировать avrasm32.exe из AVR STUDIO. Так сказать нерешенных проблем нет.

Програмы шлифовки как доработаю то выложу на Моя веб-страница

в поставке WinAVR есть каталог exapmles\demo . там есть пример makefile файла. т.е. заходите в этот каталог и наберите 'make' будут созданы bin и hex файлы, вот как раз bin файлы и надо дизассемблировать. по аналогии компилируйте и свои проекты.

ничего не понимаю второй год с GCC работаю, все нормально. Оптимизатор у него шибко умный, иногда напрягает что исчезает кусок кода, а потом посмотришь оказавается компилятор определил что условие никогда не выполнимо и соотвественноо все отрезал.
пользуйся makefile, все получается очень просто сразу на выходе получаешь elf файл и hex. elf отлаживаешь в студии, причем нормально видишь исходный текст.
Студия 4.12 позволяет делать все из под себя и сама makefile делает, не надо с ним заморачиваться.