undefined reference си означава точно това което пише - съответния символ не е дефиниран никъде в изброените сорсове и библиотеки...
Като гледам това са ти функции предвидени за портване. Демек или си взел някаква "отворена" библиотечка дето трябва да й дописваш едно-друго, или трябва да линкнеш още нещо...

Ми знам ли ги какви са. Сега като се загледах в thumb2\libc.a установих, че е в CodeSourcery (това дето мъча в момента) е къде 700Kb. Докато в yagarto \thumb\libc.a е 3Мб и кусур. Едва ли разликата идва само от двойката в thumb-a.

уф, не ми се билдва Newlib сега.... Аман.

P.S.

https://support.codesourcery.com/GNUToolchain/kbentry57

бла, бла.... абе що трябва да е просто като може да е сложно?

Борбата продължава. И е безмилостно жестока

Значи оказа се че проблема идва от линкерския фаил и библиотеката със стартъп кода. Намерих един комплект правен от някакъв ентусиаст който работи. Не ми се дизасемблира за да разбера защо това което аз имах се дънеше и то баш кога реших да включа stdio Като остане време ще го изпощя.

Междувременно реших да се направя на треснат и да питам в CodeSourcery. Казаха ми да си изтегля евалюейшън на целия пакет (досега аз ползвах Lite) и после докато трае евалюейшъна да питам. Изтеглих го - оказа се доста добре сглобена система. Туловете са билднати с малко по нови версии. Отделно еклипса си е надрънкан с плъгини, вкл. и да менажира make файлове. Въобще една завършена система са сглобили. Като за 400$ - добра алтернатива на CrossWorks се получава.

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

Естествено ми хрумна да взема от евалюейшъна само тулчейна и да го сглобя с моя еклипс, та поне да е с новите тулове. Да ама не. Вградили са проверка за лиценза даже във gcc.exe

Събота след обед е продуктивно време явно.

1. Проблема със стартъп кода вече изглежда отстранен. Сглобих една компилация между тази на ентусиаста и тази на CS.... работи добре... май.

2. Миро, установих защо не съм можел да виждам структурите с периферните регистри в expression прозореца. В твоя линкер фаил DEBUG level-a се задава като "dwarf-2". Ама така установих че elf файла е късичък - към 170К в моя случай. Като го изкомпилирам през комерсиалния CS става бая по голям. Загледах се и установих че те викат просто "-g3". Като го промених в твоя МакеFile и при моя тулчеин вече се виждат регистрите Рових по документацията да видя тая чудесия що се получава и открих следното:



Не ми стана много ясно . Както и да е.

P.S.

Оказа се че проблема е частично решен. След като включих -g3, "Някой" от #define струkтурите взеха да се виждат, други не. Общо взето периферните регистри са дефинирани като :


Такъв тип структури понякога се виждат в дебъгера, понякога не. Като отида с курсора на "GPIOA" - ми показва че е дефинирано като " ((GPIO_TypeDef *) GPIOA_BASE)". Въобще всичките дефиниции правени с #define ги вижда. Не вижда обаче дефиницията "GPIO_TypeDef" типа. Тоест не винаги. Установих че вижда тези които в програмата са предавани като параметри на функция. Т.е. ако съм предавал променлива от въпросния тип структура на някоя функция, дебъгера разпознава тази структура и в Expresions. Тези които не съм предавал като параметри, а например съм ги ползвал директно в израз - тях дебъгера отказва да ги види.

Шантава история. Явно поради някаква причина типовете използвани като параметър на функция влизат в Debug информацията. А другите не.

T.e. ако някъде имам дефинирано

GPIOA ptrToGPIOAStruct;

което после ползвам - дебъгера вижда типа GPIO_TypeDef.

Но ако просто съм използвал в кода:

GPIOA->CRL = 0x00

Дебъгера си прави пас, защото типа GPIO_TypeDef го няма в debug инфото....

Дали е някаква настройка.... Всъщност има ли начин да разгледам в някакъв нормален вариант каква дебъг информация имам в изходните файлове (.о и .elf)?

Тая опция прави всички #define видими в дебъгера. Поне такива ми са впечатленията ми на първо четене.

Ако ме беше питал дали дефайните могат да се виждат в GDB щях да те излъжа... добре че не си ме питал

Иначе други разлики при мен не откривам (засега).

Аз в много редки случаи ми се е налагало някакъв #define израз в дебъгера, (може би щото подсъзнателно съм го избягвал) но отсега нататък ще се възползвам и от тая възможност. Мерси че я откри

Има и то много: http://www.gnu.org/software/binutils/

За дъмпване на дебъг символи обикновено се ползва nm (в нашия случай arm-elf-nm).. Но не ми питай за подробности, те са 100 инструмента с 1000 опции всеки. Аз навремето като писах мейк файла пусках разни неща да генерират листинги и прочие...

при мен като пробвам да покажа GPIOA, дебъгерът го показва, като пробвам да покажа GPIO->CRL - не става
опитай само GPIOA да ти покаже

също така, ако ти казва, че няма символ GPIO_TypeDef, то може би в модула, в който си в момента, наистина няма debug информация за този тип - при мен така се получава ако - точно както казваш - просто напиша GPIOA->CRL, в този случай, в дебъг информацията се вижда следното (прилагам и проста програма, която ползвам за проба)



програмата е:


както се вижда - да, наистина дебъг информация за типа GPIO_TypeDef няма; обаче като махна коментара в реда //GPIO_TypeDef ааа;


дебъг информацията се появява, и ако искаш да гледаш израза GPIOA - трябва да работи (при мен работи); тоест - може да опиташ да дефинираш някаква неизползвана (но глобална) променлива от тип GPIO_TypeDef в модула, който искаш да дебъгваш (за да ти се генерира дебъг информация за този тип), и после да си я махнеш като си привършил с дебъга

изрази като GPIOA->CRL, обаче, май няма смисъл да се мъчиш да покажеш - едва ли ще стане

във всички примери от по-горе, компилиране с -g3 е задължително; debug информацията е изведена с objdump, но ако смяташ да гледаш по-надълбоко - изтегли си dwarfdump (objdump я показва по-примитивно)

@шопов
Точно същото се получава и при мен. Явно когато просто е дефиниран тип, без да е декларирана променлива от този тип, информацията липса в дебъгера.

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

Явно си е особенност на GNU компилатора. Сигурно си имат причина да е така. А може и да нямат , причина, а просто на никой да не му пречи достатъчно проблема. Не че е болка за умиране де. Апропо променливата не е нужно даже да е глобална или статична - и със локална в стека пак става номера. Та ако е чак толкоз зор може да се сложи една куха функция дето да ги издекларира колкото за дебъгването.

За мен е по важно, че стигнах до прозрението за -g3, щото без него си беше съвсем мъка. Ама пусто GNU - откриваш топлата вода на всеки 2-3 дена, мама му стара.

Цецо, дай някакъв линк към сайта на онзи ентусиаст от който си взел линкер скрип и стартъп файловете. Интересно ми е как това е разрешило проблема с undefined reference. Щото единственото което ми идва наум на мене е както казва шопов да се направят празни дефиниции в самия линкер скрипт. Нещо такова:
PROVIDE(_write = 0);

Линкерския скрипт няма отношение към решаването на проблема. Стартъп кода също.

Проблема си се реши частично с -g3 опцията, а останалата част от проблема ми изглежда нерешима, щото аз поне го виждам като "особенност" на компилатора. Всъщност решима е по "заобиколен"
начин с празни дефиниции (в линкерския фаил или директно в кода). Но аз поне по елегантен начин не съм намерил засега.

В стартъп кода и линкерския фаил който ползвам няма никакви дефиниции на регистри. Проблема там беше друг, че Code Sourcery имат собствена концепция за библиотеките и в частност стартъп кода. Нищо особенно, просто някой дефиниции на секции и въобще стартирането на кода, трябва да са направени по техния си начин, иначе все някога линкването гърми (при мен гръмна когато закачих stdio.). Въпросния ентусиаст просто се е поровил в комерсиалната версия на CS, която си идва с сорсовете и е преправил една версия на стартъпа и линкерския фаил za Luminary която да работи на STM32. Всъщност в последната версия на CS също има подръжка на STM32, но е направена малко постно.

Въпросния пич няма страница. Във форума на ST е прикачил неговете файлове. Ако искаш да ти ги дам, ама едва ли ще видиш нещо интересно вътре - пак казвам те нямат никакво отношение по въпроса с дебъгера, най нормални са си. Още повече че въпросния пич беше заявил, че по отношение на GDB - той с такива неща не си цапа ръцете.

Още малко да напредна в проекта, да се уверя че работят туловете що годе гладко (до колкото е възможно) и направо ще пусна тук сглобения тулчеин.

Дотук тулчейна на CS се държи прилично. еклипса също е подкаран на прилично ниво. Мейква се през скрипта на Миро. Дебъгва се през Jlink/GDB. Абе позалепнаха след 3 седмици борба нещата.....

Ти май не ме разбра. Имах впредвид именно проблема с undefined reference малко по-нагоре, а не този с дебъгването. Иначе следя темата от любопитство. Все ще дойде момент когато и аз ще трябва да търся развойни средства за Cortex-M3. Аз лично не съм много придирчив към дебъгера. Да може да служи и за loader, да има там 1-2 brakepoint-a и memory прозорец е абсолютния минимум за мен. От там нагоре каквото има в повече е добре дошло.

Да, не съм те разбрал.

Ето линкерския фаил който ползвам в момента. Както казах той е компилация от няколко източника, засега се справя добре.

Проблема с undefined reference, поне според мен, беше следния. По неведоми за мен причини (сигурно има идея някаква) CS са разбили newlib на няколко файла. Включването само на стандартната libc.a не върши особенна работа. В момента в който реших да включа stdio и то гръмна. Предполагам че са правили правили различни версии, за различните ядра във различните режими или нещо от сорта. Защото техния тулчеин има претенциите да се търкаля върху всякакви армове, а не само Cortex М3.

Та "включването" на правилните библиотеки става със следния ред от линкерския фаил:

GROUP (-lgcc -lc -lcs3 -lcs3unhosted -lcs3-stm32)

Последното е стартъп кода и дефиниция на прекъсванията и ексепшъните. Това ми беше следващия проблем, защото CS в Lite версията ги нямат готови за stm32. В последствие се оказа че имат един common, който може да се ползва, ама тогава не го знаех. В платената версия има доста добре направени за Luminary, за съжаление за STM32 отново се разчита на common версията. Която така като я гледам няма причини да не работи де. Това което не и харесах, е че дефинициите на функциите които ще обслужват прекъсванията са с имена например __cs3_isr_external_27, което не е много удобно при работа. Докато в този който аз ползвам, ентусиаста си ги е кръстил както са си на STM32 - например DMAChannel7_IRQHandler (Кортекса си има отделни вектори за всяко прекъсване, за разлика от 7TDMI, там подобна ситуация не изниква).

Абе общо взето хората които правят CS определено действат на високо ниво. Просто като скочиш на lite версията се налага в движение да откриваш топлата вода.

Апропо намерих една "прекомпилация" на туловете базирана на CS. Тя обаче си е правена само за Cortex и библиотеките просто са си компилирани за thumb2. Там въпросния проблем не изскача - всичко си има в libc.a и stdio се компилира без проблем. Но аз мисля да остана на CS. Все пак пичовете вадят редовно ъпдейти. Е сега комерсиалната вече има 2009 пролет, докато Lite е още на 2008 Q3, ама бърза работа нямам.

Апропо stdio го изключих в момента в който компилацията мина като хората. Все пак 20К Flash за един пиклив sprintf().... е нема нужда

Да не отварям нова тема.... да речем имаш битов масив в съответното адресно пространство, но то съответства на друг адрес в нормалното адресно пространство. НАпример 0x20000000 се адресира като 0x22000000, 0x22000010 i tn.
Обаче линкера има ли идея за това? Нали може да разположи друга променлива и да ти затрие битовия масив ?

Битовия масив си го декларираш като байтов да примерно в нормалното адресно пространство. Тоест резервираш си място за него. А за работата побитово си декларираш да кажем един указател и така си работиш с битовия масив.

Някой ползва ли Yagarto?

Аз реших да ъпдейтна... и голяма грешка
Асемблерът (AS) гърми с unhandled exception всеки път като се вика, а аз го викам индиректно през GCC. Отделно С-то ми бълва 1000+ предупреждения, при условие че досега нямаше нито едно...

-------
edit:
гърмежа идва от опцията -matpcs
Нямам идея що гърми, но и без тая опция се живее...