здравейте

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

та, има ли някакъв такъв дебъгер, някой от колегите срещал ли е? аз си мисля, че такова
нещо може да е доста полезно, макар и, може би, да не се налага да се ползва много често,
и може понякога да е от съществена полза?
опитът ми не е голям, какво могат да кажат опитните колеги - има ли някакъв такъв
debugger за embedded системи, за предпочитане да е free software, нещо на основата
на gdb например?

благодаря за коментарите

поздрави,
шопов

Така поставена задачата се решава с програма подобна на тази. http://www.radmin.com/index.php?r1=radm ... r3=30_home
Началника ти има възможност да работи все едно че е на твоя комп.

хм, да, това май би свършило работа
благодаря

@Шопов,

проблема ти се решава и с Remote Desktop - а на Windows-а, но аз се намесвам за да кажа, че поставяш много интересен въпрос.
Дебъгерите по принцип са локални устройства и хммм, интересно би било дали не може да се направи и на eternet. Но аз си мисля
че това не би имало много голям смисъл, т.к. дебъг процеса се улеснява много когато се наблюдават и външните въздействия от кода,
напр. ако управляваш двигател - гледаш го дали се върти, мериш обороти с външно устройство; ако пишеш на LCD дисплей - гледаш какво точно си написал и т.н. Не че не
би могло и това да се направи с камера, една или няколко, но възниква въпроса за необходимоста. Сиреч не били били по лесно
началника да се разходи до опитната постановка... ?

Има си дебъгери които са на LAN.

Има и такива към които си върви PC софтуер който представлява сървър. J-Linka за ARM има такъв. Пускаш си един лаптоп при установката и си пишеш и дебъгваш от някъде по нета. Ако искаш може да закачиш нещо друго по лаптопа да следиш каквото ти трябва.

не, май с remote desktop няма точно да стане, защото там май докато се работи от отдалечената машина, локално не може да се работи, така поне помня

всъщност на мен ми стана интересно по принцип; дебъгери, които работят по мрежа, има - например gdb, той може да работи с т.нар. gdb servers, с които може да комуникира по мрежата; аналогично, има различни графични front-ends за gdb - най-известните май са интегрираният в eclipse (не съм го ползвал - някой може ли да каже добър ли е?), ddd (data display debugger - малко само съм го пускал - изглежда да има много добри възможности за визуализация на различни структури от данни - напр. списъци), и вграденият в gdb - insight; лично аз съм работил най-много с insight (не за embedded debug, малко само съм го ползвал за embedded, имах разни проблеми с такава конфигурация), insight ми се струва нещо много добро, май не е много популярен - не знам защо

просто ми хрумна доколко би имало реална полза от някаква такава конфигурация - един target, но да може да се достъпва едновременно от различни машини; и дали изобщо има нещо такова направено?

Значи работата стои по следния начин:

Първо всеки уважаващ себе си JTAG емулатор има мрежов интерфейс. Да не говорим, че професионалните от сорта на PEEDI имат само такъв... Но ти вероятно ще ползваш нещо по-просто, аз ти препоръчвам Open OCD (Олимекс продават USB-OCD-TINY). Та OCD-то иска компютър, но като го инсталираш има драйверче и EXE, което всъщност си е сървърче и експортира TCP порт (всъщност 1 порт за GDB remote protocol и един порт за телнет). По подобен начин стои въпроса и с JLINK, само че там освен драйвера му ти трябва JSERVER или както там се казваше. Лошото е, че тоя сървър segger го продават разделно... но го има

Що се отнася до GDB, там също се ползва само един протокол и той е ремоте, т.е. GDB си приказва с таргета по TCP порт и естествено няма никакъв проблем дебъгера да ти е на едно РС, а таргета нейде на майната си...

Сега, проблемът е, че не може да се дебъгва от две места едновременно... такъв филм май досега не съм гледал. Но не е проблем да дебъгваш от едно място, да спреш и да продължиш от друго място (компютър). Само трябва да се синхронизирате, щото пак казвам не става един порт да се отваря от две места едновременно.
За целта трябва да си прегледаш внимателно скриптовете които се изпълняват при пускане на GDB, щото има нещо като практика при тръгване да се ресетва таргета, а ти предполагам не искаш това. Но при GDB всичко се контролира... Ако ползваш Eclipse там задаваш с какви параметри да се извика и какви комадни да изпълни... На теб не ти трябва нищо повече от "target remote" и евентуално "load" на elf-а или каквото ползваш. Но дори и тях може да махнеш и да си ги пишеш ръчно...
Най-добре е да си ги огормиш като 2-3 буквени команди тия работи и да си ги сложиш в един файл ".gdbinit". Но и тук трябва да внимаваш защото тоя файл да не съдържа команди дето се изпълняват автоматично. Може само 'hook-ве" да си оставиш и другото само с define да си го направиш като твои команди които да викаш през конзолата когато трябва...

Сега след като заредиш GDB-to, конектнеш се към таргета, дадеш load на елф-а по принцип нищо не става. В смисъл не виждаш къде е спрял таргета. Може и да има и по-умен начин, но аз знам само тоя - "si". Това е изпълнение на single instruction, и то като е изпълни вече се пробва да ти намести сорса както и където трябва.
бтв, ако ползваш Insight, той без да пита си изпълнява .gdbinit така че внимавай да не ти пипне таргета... Но ако имаш Eclipsе изобще не ти трябва Insight-a

Та така... по тоя начин ще можете да се "редувате" с шефа си и да дебъгвате едновременно... Значи променливи едно-друго който е вързан на таргета ги вижда, но ако ти си сложил да речем някакви брейкпоинти и излезеш, то шефа ти като влезе няма да вижда брейкпоинт ватчове и т.н. Но GDB-то си има команди да си листваш текущите и списъка може да го пращаш на шефа си по ICQ ако трябва, ако не той ще трябва да си ги слага наново.
Освен може би ако не слгаш и настройките в CVS/SVN... To по принцип ако работи повече от 1 човек е почти задължително да се ползват такива неща.... Не знам през Insight, но плъг-ина на Eclipse си помни брейкпоинти и разни настройки, само дето не знам дали няма пътища из тях, т.е. да не става да се прехвърлят на друга машина...


В крайна сметка това с remote desktop също не е лоша идея. Но аз ти препоръчвам да си сложите някаква лайнокс машинка, на която и GCC да е натив и слагаш един еклипс там и си бакчаш ремоте. Аз така правех доста време, щото предпочитам да си стоя на Windows машината, пускам си графичен клиент към X-сървъра и практически всичко е много по-удобно и работи по-бързо, отколкото ако ти е инсталирано на бозата. Особено компилирането, ако под windows отнема 10-на секунди на линукса е части от секундата.
Сега не мога да ти кажа дали графичните сървъри позволяват да се логнеш едновременно от 2 места и да гледаш кво става. Би трябвало щото за Windows има такива. В краен случай пак ще се редувате, но поне всичко ще се запазва и няма да се губят брейкпоинтовете...

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

Примерно GDB
http://www.gnu.org/software/gdb/