дебъгването е същото от версия 4, някой път прескача, някой път не, въобще един фрагмент минах 100 пъти докато го хвана какво прави, а уж трябваше да е лесно

Не съм му ползвалдебъгването на 4 ката. Но ме навежда на мисълта че след като с две тотално различни среди го има този проблем той е в листинга който компилатора дава на дебъгера.

Среща ли се и в другите GCC компилатори такъв проблем?

Почти не ползвам дебъгери.
Сигурен ли си че си сложил "-O0" и че има желания ефект?

Да с оптимизация кода става 3 пъти по малък.

"Един ден пулене в кода спестява 10 минути досадно дебъгване"

Да, при PIC32 се среща. При PIC24x/dsPICxx не ми е правил проблем. При XC компилаторите им не знам дали има такъв дефект, още не мисля да ги инсталирам, ще изчакам да отлежат година-две и тогава.

Преди сигурно година бях пуснал подобна тема за PIC32 и GCC, и не се намери смислен отговор на въпроса ми, защо след като се оптимизира не може да се дебъгва прилично. В крайна сметка програмния брояч на кой да е професора тегли и изпълнява последователно кода, така както е зареден в програмната памет.

То това се оказва и повърхноста на проблемите с GCC за AVR.
Ей например тази структура


Бях направо учуден че прави чак толкова примитивна грешка като пишеш в destaddr16. Пише някъде на майната си по паметта. Интересно че srcaddr16 се пише нормално.
За всеки случай го минах на IAR да съм сигурен че грешката не е в мен. Няма проблем.
После пробвах както на едно място правилно работят с тази структура. Ако се пише последователно по всички членове на структурата се пише вярно и в destaddr16.

Общи линии простотии които бях забравил от времето когато съм писал с Hi-Tech и PIC. Не знам как може да се работи с това GCC. Ни дебъгване работи,ни вярно компилира,ни документацията е нормална. Направо се хванах за главата. А толкова хора тук споделят че работят с това нещо. Направо съм учуден.

Да не би AVR GCC да иска union да е подравнен на четен адрес ? Имаш в полето 16-битова променлива.

Току що хаванх проблема. Пак бил в дебъгера. Аз присвоявам стойноста на една променлива на destaddr16 и дебъгера си ми показва че тя има някаква стойност. След присвояването destaddr16 си остава в нула и аз автоматично решавам че пише някъде на майната си.
Само че се оказва че дебъгера ми покзава грешно стойноста на тази променлива и тя в действителност си е 0.
Като погледнах в асемблера и регистрите се усетих.
Ама то така не може да се работи. На инструмента трябва да може да се вярва.

Между другото имах такъв проблем с PICKit3 и MPLAB X миналата седмица. До този момент бях с MPLAB X 1.10 и кода си беше наред, инсталирах MPLAB X 1.20 и нещата се омазаха, дебъгера ми показваше няколко променливи с грешни адреси. След ден-два чуденки затрих проекта и го направих наново в MPLAB X 1.20 и проблема изчезна. Обяснявам си го с някакво разминаване при компилация в новата версия с използване на стар ELF файл от старата версия.

При мен не е такъв случая,съвсем прясно инсталирана среда. Пък и проблема с дебъването явно си ги има още от 4 та версия.

има си bugzilla за GCC и там всеки може да провери и докладва бъг на GCC. Отделно към всеки релийз има и подробно описания кое е фикснато или променено.
По същият начин е и с GDB...

Досега обаче аз бъг не съм успял да открия (да чукна на дърво ) нито пък съм се сблъсквал с такъв. Всъщност само веднъж и то при компилацията на самото GCC щото ние под лайнукса не ползваме ЕХЕ-та, а сорсове... Та имаше един момент в който GCC-то на РС-то ми беше с по-нова версия и откриваше повече неща като забележки и поради това не искаше да компилира старо GCC от ягарто. Видях къде и защо и си ги оправих сам, та това е единственият случай за който се сещам. Иначе в началото ми се е случвало да се съмнявам много.... ама хайде да не забравяме че с едно и също GCC се компилира и самото GCC и лайнукси и андроиди и какви ли не неща.
Компилират се милиарди редове код... писан от най-различни хора и през толкова много години (при всяка версия на GCC всичко се прекомпилира). Така че айде много моля всеки новобранец след 2 дена работа да не открива толкова много бъгове

И другото, когато имате съмнения първо се проверяват нещата в нейтив режим. Ако е за компилатора -> команд промпт да се види какво е накаран да направи и листинг какво е направил. Ако е дебъг - gdb конзола и там се работи. Забравете тия визулните истории в началото! Първо защото в тях наистина има бъгове и тия бъгове се влачат с години, щото хората с опит рядко ползват такива неща. Аз разбира се ползвам, ама при съмнения винаги си отварям конзола. А специално за дебъга почти всичко правя само в конзола. Много по-удобно е и много по-бързо се работи!
Това не е от любов към мазохизма или някаква секта. Просто много неща няма как да се направят визуално. Примерно в конзолата мога да си видя коя да е променлива, мога да си извикам коя да е функция от кода, да правя тайпкастове, сметки, конверсии. По-често срещаните неща си ги оформям като скриптове с две букви, примерно "сс" ми прави къстъм ресет на таргета "tt" ми показва тасковете и т.н. Общо взето с две чуквания по клавиатурата виждам или правя каквото ми трябва. Ако тия неща трябваше да са визуални щях да имам 1000 джама и 1000 бутона и постоянно да се лутам като замаян....

Другият проблем е, че визуалните плъгини винаги нещо не е както хората. При АРМ едва напоследък има сравнително читави графични среди. До преди година си беше мъка. То и сега не е цвете де... Но за елементарни неща става. И то толкова ми трябва де - да мога да навигирам step in, step over и да вижам локалните променливи. Демек нещата дето се правят само с един бърз клавиш, т.е. да отида до кода дето ще дебъгвам... и от там вече минавам в конзолата

Не знам как ги виждаш толкова розово нещата. Аз като един нормален юзер си инсталирам средата заедно с компилатора. И очаквам да работи. Ей тая тъпня с грешно показваната променлива ми умори няколко часа. Отделно що пулене и щракане по опциите докато разбера че в крайна сметка както и да ги въртя,дебъга за нищо не става.
Може би за арм е по читава хавата знам ли. Там има и линейно адресно пространство. При AVR е разделено. Отделно има различни стекове за адреси за връщане и за данни. С GCC са ги обединили някак още не съм схванал идеята. Но бозата е сериозна.
Ползвам няколко различни среди. Не е като да нямам опит.
Имам и още един опит с GCC компилатор,средата на Siera Wireless /WaveCom/ под Eclipse. Там дебъга също не става за нищо. Просто се отказах да го ползвам. Бях набедил WaveCom за тия проблеми но може да се окаже че основата на проблема е в GCC и изхода който дава на дебъгера.

Кво да ти кажа, аз като почвах с АРМ също пищях за документации и тогава много от нещата бяха още малко недодялани... Ягартото още беше с допотопни версии, Еклипса беше с някакъв куц плъгин, то и още стандартния плъгин на CDT-то не става, аз затова ползвам един на Zilyn.
Абе позната картинка, единствено че тогава имах приятели дето ми показаха как стават нейтив нещата, даже в началото дебъгвах с Insight... Ти ако го пуснеш това сигурно ще се изприщиш Пълно дърво като интерфейс, обаче бачка като истинско джелязо

Просто дебъгерът GDB е правен като за конзола и за човек да гледа. Фронтендовете нямат интелекта на човек и затова правят глупости. Примерно ти имаш бъг и си омазваш стека. Фронтенда обаче за да покаже откъде си дошъл казва на GDB-то да му направи unwind на омазания стек. Съответно GDB-то му казва дошъл си от еди-коя си функиция. Фронтенда е добавя в джама и тръгва да търси тя пък от къде е извикана. При определени данни обаче може да се получи безкрайна рекурсия.
В случая GDB-то (инстинският дебъгер) няма абсолютно никаква вина. Прави каквото му се казва. Фроненда (като изключим Insight) пък няма интелекта да се усети, а и не му е работа. Вината е 100% в теб щото твоят бъг е омазал стека и щото не си сложил лимит колко дълбоко да се unwind-ва. Но докато разбереш всичко как става....
Подобен проблем някак да ти се случи под IAR защото вероятно имат лимит във фронтенда и едва ли позволяват гимнастики със стекoвия указател и т.н. Обаче с IAR посмъртно не можеш да дебъгваш Линукс кърнели или големи приложения. А в GDB не може да очакваш подобно ограничения защото той е правен за големите риби, не за простите приложенийца дето ги пишем ти и аз...

Опитвам се да ти обясня, че нещата не са толкова прости - "розови" за моминченца и "сини" за момченца
Ако търсиш простичко карай на IAR и си свиркай... Ако ще минаваш на GCC & GDB ще се наложи да се погърчиш малко, защото за много неща се изисква опит и знания от задклавиатурното устройство
Между другото аз не виждам смисъл да разучаваш GCC, GDB и компания само за един AVR. Още повече че едва ли за него всичко е портнато както трябва... Мноооого се съмнявам. Виж ако ще го ползваш за няколко платформи е ОК, струва си усилията. Ама за една и то една от най-неподходящите... ти си знаеш де

Доста време мина. Някой да се е блъскал със студиото и да има някакви наблюдения върху дебъга?
Просто не може да се работи с това дърво по мои наблюдения.
Но все пак ми се иска някой дето е на ти с проклетата гнус да го е пипнал и да си каже мнението.

Иначе вярно си компилира гадината но без дебъг си е дърво.

Ща пак не пробваш Microchip?