Абе имам от време на време следния проблем с еклипс:

Определен код ми го маркира че е "невалиден" и не желае да го дебъгва като хората. Обикновенно се случва когато имам #ifdef игрички с няколко вложени .h файлове. Иначе се компилира като хората, работи си, ама като тръгна да дебъгвам, се оказва че тоя код сивее - я не ще да слага точки на прекъсване вътре, я ги слага на съвсем други места.

Има ли команда да седне да си прегледа структурата на проекта и си опресни базата? "clean + Build all" не помага.

Първо виж дали всички h-файлове "се виждат" от Еклипса, ако трябва му задай ръчно инклудите в C/C+General->Paths and Symbols...

После виж дали "вижда" всички define-и. Ако на компилатора му ги задаваш в мейкфайл или като параметри то Еклипс няма как да знае това. Пак ръчно може да ги добавиш към symbols...

Добре е да провериш и настройките на скенера - C/C++ Build->Discovery Options...


A иначе специално за #ifdef то се вижда кои символи не обработва правилно. Маркираш съответния символ и с F3 виждаш къде го намеира или не намира Еклипса...

Здравей! При мен се получава понякога подобни неща и го оправям периодично с десен бутон върху полето с номерата на редовете, Folding->Reset Structure. Забелязал съм, че това става ако използваш в програмата структура допустима за компилатора но различна от стандартната.

Че не вижда #define -те е ясно. Като цъкам с F3 по макросите и ме гледат тъпо (т.е. нищо). Но интересното е че на два еднакви на вид проекта - се справя на единия с намирането, а на другия не.

Пак казвам проблема ми е с визуализацията в еклипса, проекта си се компилира правилно.

Явно не може да се ориентира в структурата на директориите. Аз не му включвам нищо в Path и Symbols, обикновенно след една компилация сам си открива всичко. Директориите ми се инклудват в мейкфайла, да, ама обикновенно Еклипса се оправяше, а сега неще.

Абе проблема е че се опитвам да портна ucGUI, а това чудо има сигурно няколко мегабайта сорсове и няколко хиляди файла оплетени в една идиотска мрежа от #define, #ifdef и прочие.... И на един проект беше станало като хората. А сега на следващия - не ми се получава и не мога да го дебъгна като хората. И не виждам разликата от къде иде мамка му.

Ясно де, разбрахме че визуализацията е проблема, въпросът е ти дали си наясно че компилацията няма нищо общо с визуализацията

Еклипса сам си се ориентира (може да ползва gcc за анализа ако му кажеш, но по подразбиране не го ползва). Виж да не си изключил сканирането и да не ти опреснява...

Значи много е просто - всички хедъри от проекта се парсват, освен това Еклипс се опитва да следи какви външни хедъри ползваш и ти ги слага в една #include папка в проекта.

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

Абе аз знам че ти е ясно, ама да поясня.

И на мен ми е ясно това което казваш. Или поне си мисля, че ми е ясно. Наслагах ги в Path и Symbols - пак дърво. Всъщност лъжа - те се бяха наслагали сами там, което показва, че еклипса се ориентира добре във дървото на проекта.

Всъщност "оправих" го де. Много тъпо - значи в проблемния сорс код, просто включих на "първо" ниво файла с дефинициите "#include bla-bla.h". И естествено веднага сивотата изчезна. После го махнах и сивотата не се появи повече. Нещо ме гложди, че и предишния път така го "оправих". Сякаш еклипса по подразбиране не се сеща да гледа вложени един в друг include файлове, а зяпа само първия. Веднъж като открие даден символ обаче, запомяна в кой фаил е го следи. Не е проблем на директории, защото и първото ниво и последващите include файлове са в една и съща директория....

Десен бутон върху проекта -> Index -> Rebuild. По някой път захапва...

Нов въпрос - в дебъг (Zylin ако има значение), прозорчето за памет, всеки път ми се отваря на 32 битови числа. В повечето случаи ми е удобно на байтове. Има ли начин да го запомни и да не досажда?

А, за да не отварям нова тема, на LD Linker-a разбирате ли му?

miro е човека До колкото въобще някой може да каже че това нещо може да бъде разбрано

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

Та значи......

Както знаете аз харесвам и предпочитам Pascal. (Тук моля да пропуснем темата: C vs. Pascal)... И една сутрин като се събудих, реших че французите дето направиха Pascal за ARM не може да са по - умни от нас, и се хванах да си билдна един компилатор. Дръпнах си FPC, изградих крос компилатор за ARM и тръгна. Подкарах и Lazarus като среда. По дефолт, поддържа само 2-3 чипа от серия LPC21xx. Направих поддръжка за LPC2468. Генерираните hex файлове работят. Проблем беше, че тъй като няма директива #pragma, а имам и външна памет - как да кажа коя променлива къде да отиде, но с това се справих като добавих в линкерския скрипт даден файл къде да се разположи. После взех един object file от колега, който инициализира таймер и експортва функция Delay, компилиран на IAR C. Декларирах прототипите, линкнах файла и го ползвам без проблем от Pascal.
Проблема е, че ако примерно в С кода някъде има използвано нещо от библиотеките на IAR (memcpy примерно), програмата се компилира, генерира се hex file, но не работи. Или да опитам да подкарам линкера на IAR?!?

Значи LD-то не се интересува какъв ти е компилатора, важното е да му дадеш обектни файлове и библиотеки в разбираем за него формат.

По принцип с LD ходи и набор от разни "стандартни" библиотеки като libc примерно. И те се ползват автоматично, освен ако не включиш опции като "-nostdlib".

Освен самите библиотеки има и стандартни хедъри, така че поне на Ц не е нужно да декларираш прототипите на стандартните функции, достатъчно е да инклуднеш само стандартния хедър. За Паскал-компилатор не знам, може и да трябва.

Така или иначе щом се компилира значи нямаш проблем с хедърите. А може и да имаш като декларациите ти не съответстват по тип/параметри с кода от библиотеките.
Щом се линква, значи че и намерило и код за всички функции дето викаш.

А това, че не работи може да е резултат от:
1) грешна декларация. Примерно ти си декларирал функцията с един набор параметри, а тя реално е с различен брой/подредба или тип параметри. За съжаление линкера не хваща такива грешки, той гледа само имената да съответстват. То затова и Ц++ декорира имената...
2) Грешна calling конвенция. Доколкото си спомням Паскал имаше собствена конвенция за някои неща, различна от Ц/Ц++. Освен това самият АРМ има няколко конвеции (EABI, non-EABI)
3) Не бих се изненадал и ако има различия в това що е то обектен файл между IAR и GCC...

Въпросът е как да разбереш какъв е проблема... Сещам се за два варианта:
1) Да генерираш детайлни листинги и да видиш какви ги е надробило.
2) Да вземеш и да го дебъгнеш и пак да видиш какви ги е надробило.
А има и 3-и вариант - да се бориш с IAR-кия линкер...

Ето това е линкерският ми скрипт:



Секциите [Bold] съм ги добавял аз. Може ли малко по детайлно обяснение, какво точно прави линкера и защо като преместя секция 'api_r' в на1алото на срипта и се сбозва работата?

Аз няма как да ти кажа защо се сбозва... но ти сам много лесно може да го разбереш защо

Когато компилатора генерира обектните файлове, той указва коя променлива/обект в коя секция да бъде разположен. За линкера това са т.н. "входни секции".

Сега в линкерския скрипт ти в "SECTIONS { ... }" дефинираш "изходните секции" както и правила коя входна секция в коя изходна искаш да отиде.

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

Освен това както си го направил редът има значение! Най-вероятно твоят timer.o съдържа код, т.е. функции, които по принцип компилатора слага в .text. Може да имаш статични променливи, които по подразбиране са в .bss, инициализации в .rodata и т.н. и т.н.
Сега както е написан скирпта като почне да се линква timer.o първо ще се срещнат правилата за .text, .bss и т.н. и което пасне на тези правила ще се разположи в съответните изходни секции. И когато стигне до края - в api_r имаш правило да сложи "всичко" от timer.o. Но под всичко, разбирай всичко което е останало нелинкнато от горните правила.

Ако изместиш обаче тая api_r в началото, тогава ще започне със "всичко" а то наистина в началото е "всичко" и всичко от timer.o ще се пльосне във флаша... Ако така го искаш няма проблем Въпросът е че аз нямам идея нито какво искаш, нито какво се получава... Гледаш листингите и проверяваш, функциите там където ги искаш ли са, променливите на място ли са, инициализации и т.н.

И по възможност избягвай директно да упоменаваш цели файлове. Работи само с правила коя входна секция в коя изходна да отива...