| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| Еклипс въпроси http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=8523 |
Страница 1 от 2 |
| Автор: | Цецо [ Пон Фев 07, 2011 12:34 pm ] |
| Заглавие: | Еклипс въпроси |
Абе имам от време на време следния проблем с еклипс: Определен код ми го маркира че е "невалиден" и не желае да го дебъгва като хората. Обикновенно се случва когато имам #ifdef игрички с няколко вложени .h файлове. Иначе се компилира като хората, работи си, ама като тръгна да дебъгвам, се оказва че тоя код сивее - я не ще да слага точки на прекъсване вътре, я ги слага на съвсем други места. Има ли команда да седне да си прегледа структурата на проекта и си опресни базата? "clean + Build all" не помага. |
|
| Автор: | miro_atc [ Пон Фев 07, 2011 12:46 pm ] |
| Заглавие: | |
Първо виж дали всички h-файлове "се виждат" от Еклипса, ако трябва му задай ръчно инклудите в C/C+General->Paths and Symbols... После виж дали "вижда" всички define-и. Ако на компилатора му ги задаваш в мейкфайл или като параметри то Еклипс няма как да знае това. Пак ръчно може да ги добавиш към symbols... Добре е да провериш и настройките на скенера - C/C++ Build->Discovery Options... A иначе специално за #ifdef то се вижда кои символи не обработва правилно. Маркираш съответния символ и с F3 виждаш къде го намеира или не намира Еклипса... |
|
| Автор: | fan [ Пон Фев 07, 2011 12:51 pm ] |
| Заглавие: | |
Здравей! При мен се получава понякога подобни неща и го оправям периодично с десен бутон върху полето с номерата на редовете, Folding->Reset Structure. Забелязал съм, че това става ако използваш в програмата структура допустима за компилатора но различна от стандартната. |
|
| Автор: | Цецо [ Пон Фев 07, 2011 1:19 pm ] |
| Заглавие: | |
Че не вижда #define -те е ясно. Като цъкам с F3 по макросите и ме гледат тъпо (т.е. нищо). Но интересното е че на два еднакви на вид проекта - се справя на единия с намирането, а на другия не. Пак казвам проблема ми е с визуализацията в еклипса, проекта си се компилира правилно. Явно не може да се ориентира в структурата на директориите. Аз не му включвам нищо в Path и Symbols, обикновенно след една компилация сам си открива всичко. Директориите ми се инклудват в мейкфайла, да, ама обикновенно Еклипса се оправяше, а сега неще. Абе проблема е че се опитвам да портна ucGUI, а това чудо има сигурно няколко мегабайта сорсове и няколко хиляди файла оплетени в една идиотска мрежа от #define, #ifdef и прочие.... И на един проект беше станало като хората. А сега на следващия - не ми се получава и не мога да го дебъгна като хората. И не виждам разликата от къде иде мамка му. |
|
| Автор: | miro_atc [ Пон Фев 07, 2011 1:41 pm ] |
| Заглавие: | |
Ясно де, разбрахме че визуализацията е проблема, въпросът е ти дали си наясно че компилацията няма нищо общо с визуализацията Еклипса сам си се ориентира (може да ползва gcc за анализа ако му кажеш, но по подразбиране не го ползва). Виж да не си изключил сканирането и да не ти опреснява... Значи много е просто - всички хедъри от проекта се парсват, освен това Еклипс се опитва да следи какви външни хедъри ползваш и ти ги слага в една #include папка в проекта. Сега ако имаш хедър, който не е парснат виж къде е... дали е в проекта, ако не дали го е открило къде е, или ти трябва да го добавиш ръчно както ти описах по-горе (аз по принцип изключвам аутоматиките и си слагам ръчно пътищата, та да не стават сакътлъци...) |
|
| Автор: | Цецо [ Пон Фев 07, 2011 2:05 pm ] |
| Заглавие: | |
Абе аз знам че ти е ясно, ама да поясня. И на мен ми е ясно това което казваш. Или поне си мисля, че ми е ясно. Наслагах ги в Path и Symbols - пак дърво. Всъщност "оправих" го де. Много тъпо - значи в проблемния сорс код, просто включих на "първо" ниво файла с дефинициите "#include bla-bla.h". И естествено веднага сивотата изчезна. После го махнах и сивотата не се появи повече. Нещо ме гложди, че и предишния път така го "оправих". Сякаш еклипса по подразбиране не се сеща да гледа вложени един в друг include файлове, а зяпа само първия. Веднъж като открие даден символ обаче, запомяна в кой фаил е го следи. Не е проблем на директории, защото и първото ниво и последващите include файлове са в една и съща директория.... |
|
| Автор: | setoy [ Пон Фев 07, 2011 2:57 pm ] |
| Заглавие: | |
Десен бутон върху проекта -> Index -> Rebuild. По някой път захапва... |
|
| Автор: | Цецо [ Пет Фев 18, 2011 4:15 pm ] |
| Заглавие: | |
Нов въпрос - в дебъг (Zylin ако има значение), прозорчето за памет, всеки път ми се отваря на 32 битови числа. В повечето случаи ми е удобно на байтове. Има ли начин да го запомни и да не досажда? |
|
| Автор: | relsys [ Пет Фев 18, 2011 5:17 pm ] |
| Заглавие: | LD Linker |
А, за да не отварям нова тема, на LD Linker-a разбирате ли му? |
|
| Автор: | Цецо [ Пет Фев 18, 2011 6:41 pm ] | |||||||||
| Заглавие: | Re: LD Linker | |||||||||
miro е човека |
||||||||||
| Автор: | ДедоБоре [ Пет Фев 18, 2011 7:52 pm ] |
| Заглавие: | |
ти си излей мъката, пък може да се окаже, че някой му разбира. ако не му разбира вероятно няма да се обади. |
|
| Автор: | relsys [ Съб Фев 19, 2011 1:51 pm ] | |||||||||
| Заглавие: | ||||||||||
Та значи...... Както знаете аз харесвам и предпочитам 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?!? |
||||||||||
| Автор: | miro_atc [ Съб Фев 19, 2011 4:02 pm ] |
| Заглавие: | |
Значи LD-то не се интересува какъв ти е компилатора, важното е да му дадеш обектни файлове и библиотеки в разбираем за него формат. По принцип с LD ходи и набор от разни "стандартни" библиотеки като libc примерно. И те се ползват автоматично, освен ако не включиш опции като "-nostdlib". Освен самите библиотеки има и стандартни хедъри, така че поне на Ц не е нужно да декларираш прототипите на стандартните функции, достатъчно е да инклуднеш само стандартния хедър. За Паскал-компилатор не знам, може и да трябва. Така или иначе щом се компилира значи нямаш проблем с хедърите. А може и да имаш като декларациите ти не съответстват по тип/параметри с кода от библиотеките. Щом се линква, значи че и намерило и код за всички функции дето викаш. А това, че не работи може да е резултат от: 1) грешна декларация. Примерно ти си декларирал функцията с един набор параметри, а тя реално е с различен брой/подредба или тип параметри. За съжаление линкера не хваща такива грешки, той гледа само имената да съответстват. То затова и Ц++ декорира имената... 2) Грешна calling конвенция. Доколкото си спомням Паскал имаше собствена конвенция за някои неща, различна от Ц/Ц++. Освен това самият АРМ има няколко конвеции (EABI, non-EABI) 3) Не бих се изненадал и ако има различия в това що е то обектен файл между IAR и GCC... Въпросът е как да разбереш какъв е проблема... Сещам се за два варианта: 1) Да генерираш детайлни листинги и да видиш какви ги е надробило. 2) Да вземеш и да го дебъгнеш и пак да видиш какви ги е надробило. А има и 3-и вариант - да се бориш с IAR-кия линкер... |
|
| Автор: | relsys [ Пон Фев 21, 2011 11:59 am ] | |||||||||
| Заглавие: | ||||||||||
Ето това е линкерският ми скрипт:
Секциите [Bold] съм ги добавял аз. Може ли малко по детайлно обяснение, какво точно прави линкера и защо като преместя секция 'api_r' в на1алото на срипта и се сбозва работата? |
||||||||||
| Автор: | miro_atc [ Пон Фев 21, 2011 12:46 pm ] | |||||||||
| Заглавие: | ||||||||||
Аз няма как да ти кажа защо се сбозва... но ти сам много лесно може да го разбереш защо Когато компилатора генерира обектните файлове, той указва коя променлива/обект в коя секция да бъде разположен. За линкера това са т.н. "входни секции". Сега в линкерския скрипт ти в "SECTIONS { ... }" дефинираш "изходните секции" както и правила коя входна секция в коя изходна искаш да отиде. В случая ти правиш много странни неща, дето аз бих избегнал да правя. Примерно в изходна секция пляскаш директно обектен файл, а от къде си сигурен, че всичко от тоя обектен файл трябва да е само в една изходна секция? Утре ще сложиш променлива или нещо в сорса и ще се чудиш що не работи... Освен това както си го направил редът има значение! Най-вероятно твоят timer.o съдържа код, т.е. функции, които по принцип компилатора слага в .text. Може да имаш статични променливи, които по подразбиране са в .bss, инициализации в .rodata и т.н. и т.н. Сега както е написан скирпта като почне да се линква timer.o първо ще се срещнат правилата за .text, .bss и т.н. и което пасне на тези правила ще се разположи в съответните изходни секции. И когато стигне до края - в api_r имаш правило да сложи "всичко" от timer.o. Но под всичко, разбирай всичко което е останало нелинкнато от горните правила. Ако изместиш обаче тая api_r в началото, тогава ще започне със "всичко" а то наистина в началото е "всичко" и всичко от timer.o ще се пльосне във флаша... Ако така го искаш няма проблем И по възможност избягвай директно да упоменаваш цели файлове. Работи само с правила коя входна секция в коя изходна да отива... |
||||||||||
| Страница 1 от 2 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|