арм дебъгер

здравейте, колеги; искам да ви питам нещо, аз се мъча да направя дебъгер за арм процесори, донякъде успявам, но е много мъчно и не знам кога ще мога да пусна първата версия на тоя дебъгер; аз исках да го продавам като софтуер, обаче много се оплетох и сега ползвам много open-source части, и така че май няма да мога да го продавам, а ще трябва да го пусна като open-source и аз, но вече май съм се примирил с това; може пък да успея да изработя евтини jtag-ове, като например wiggler-клонинги и така да припечеля нещо, много труд и време съм вложил и ми се иска да припечеля, но кой знае... съдбата си знае работата...

по същество - искам да ви питам - има ли тук някой интерес от такова нещо? като цяло, това ще е дебъгер за хора аматьори, любители на арм-овете, които не могат да отделят много средства за развойни действия; прилагам тук screenshot-ове на тоя дебъгер, но подробности много още не мога да сложа тук, защото не е готов тоя дебъгер, и, изобщо, нужна ми е още поне една година да ги приведа нещата в хубав и приятен вид; като цяло, тоя дебъгер ще поддържа на филипс бая от процесорите, които са arm7tdmi-s, и също wiggler-а; аз много ви се моля да не ме пустосвате твърде много, това е просто една програма, с която много се стремя да припечеля, и тука искам да питам по-скопосните колеги - дали виждат идея в цялото това начинание? ето, прилагам картинките

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

Може да се свържиш с ronetix, ето ти контакт http://mcu-bg.com/mcu_site/viewtopic.php?t=6619 Те по принцип се интересуват, ама не точно от "просто една програма"...

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

По принцип трябва да насложиш сума ти абстракции за да го доведеш до нивото на това с което хората са свикнали и очакват. Е, може да опиташ с нещо по-просто и хитро като интерфейс и работа (разбирай, кандидат-революционно), но рискуваш още повече. Дори не трябва да е за ARM точно, а да е общ дебъгер. И не само за един таргет, ами за няколко наведнъж. Дистанционни. И да има вграден 'C'-подобен скриптов език за да може да се програмират сложни интеракции м/у таргетите и точките на прекъсване. И така почват да се натрупват генерализациите и изпадаш в бездънната яма.

После ти идва проблемът че сигурно компонентите които ползваш не са LGPL ами GPL.

И още по-бруталното - предполагам визираш потенциална ниска цена в контраст с предложенията на "големите". Но там според мен пазар няма. Сигурно се сещащ примерно масата потребители на този форум колко $$$ са дали за софтуер и колко планират да дадат.

Освен това, няма ли избор от поне няколко FOSS предложения за ARM дебъг?

Откъм добрата страна, виждам че имаш дизасемблиране на кода с примесване на сорса, някакъв stack-unwinding, показване на структури от данни ... не е зле за начало. Но - прочети пак коментара ми от начало и инвестирай труда си (ако е с комерсиална насоченост) в друга посока.

Поздрави!

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

Ако правиш нещо евтино (което мисля ти е идеята) - то трябва да направиш големи количества. Само че в Бг големите количества на подобен продукт са нереализиуеми по няколко причини:

1. Такива безплатни варианти са налични и сега.
2. В БГ все още не е проблем да се ползват и скъпи варианти, без да е нужно да се плаща, особенно когато говорим за аматьорски нужди.
3. Пазара в БГ като цяло е силно ограничен. Аз без да съм правил маркетингово проучване, мога смело да кажа, че пазара за подобен продукт в БГ е под 100 броя, от които ти можеш да вземеш не повече от 20% при перфектен продукт.

В сегмента в който опитваш да влезеш вече са Олимекс. Имай и това предвид.

И въобще златното правило е - много бройки/ниски цени или малко бройки/високи цени. Лично аз винаги се целя във второто. Там е истината, особенно в БГ, на бройки не можеш да разчиташ по никакъв начин.

Както каза и miro що не се свържеш с колегата ronetix. Те се занимават с продукти точно в тоя бранш, само че на професионално ниво. Човека до скоро търсеше и хора (при това доста безуспешно за жалост, май).

най-напред, благодаря ви, колеги, отговорите ви звучат откровено, аз се надявах това да чуя



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

ползвам:
libdwarf - lgpl
дизасемблера на binutils - това май наистина НЕ Е lgpl
ncurses - не съм проверявал
xlib - не съм проверявал
изтърбуших и съвсем малко доработих симулатора на армове от gdb - това със сигурност не е lgpl, затова написах връзка към този симулатор през socket-и, но май така не става, миналата седмица се опитах да разбера законния статус на такава комбинация - и като че ли - не може да ползвам такава комбинация комерсиално
имам и заготовка за qt инерфейс, обаче това го правих само за проба, qt струва много пари, които нямам

благодаря ви за откровените отговори, дано да мога скоро пак да напиша нещо смислено

Първо, за да успееш, трябва да имаш документация на ниво, преди още да си завършил проекта. Ще ти е нужно да привлечеш спонсори, а показвайки 2 снимки как изглежда екрана не е достатъчно да накараш някой инвеститор да разпаше кесията, трябва да го омотаеш с потенциалните възможности на продукта. Тук има хора, които и от тези две снимки ще разберат докъде си я докарал ( на мен и 10 да ми дадеш, пак ще гледам умно ), но инвеститора надали ще е специалист. Ако решиш пък да отвориш кода и да го публикуваш някъде, със сигурност ще се намерят хора, които ще ти помогнат и за 1г. ще завършите проекта ( явно вече си се настроил, че няма да си възстановиш вложените средства, затова поне нека остане като награда насладата, която ще изпиташ пред завършения проект ), а и може и някоя с комерсиални цели да се заинтересува от проекта ти и да те привлече на добре платена работа.

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

Шопов,
странно защо, но имам чувството че не познаваш добре конкуренцията
Повечето дебъгери имат скриптове. Някои са ограничени само до hook функции като IAR примерно. Други имат и командна конзола, от която по всяко време потребителят може да извиква различни неща, примерно като GDB.
Хук функциите са задължителни, както казва woody без тях до никъде няма да стигнеш. Причината е, че дебъгерът управлява всичко, от това да се конектне с таргета, да го ресетне, да качи някакъв софтуер и чак най-накрая се стига до същинското дебъгване. Всичко до дебъгването се прави със скриптове, защото е уникално за всеки таргет.
Пример имаш ARM само с JTAG... включваш го и докато емулатора се усети процесора вече е захапал някакъв код и е омазал половината периферия. Истински ресет нямаш. Какво ще дебъгваш после с омазана периферия?
Ти в дебъгера не можеш да ресетваш периферията, просто защото не знаеш какво клиента е налепил на платката (освен ако не си роднина на Ванга). От друга страна клиента няма да седне да ти пипа сорсовете дори и да му ги дадеш. Така че остава едно единствено решение -> скрипт. Ти в дебъгера при всяко събитие и по-важно действие викаш съответната hook функция, която потребителя може да си модифицира/напише по свой вкус.
Скрипта трябва да дава възможност да се чете/пише по таргета, както и всичко друго което имаш като функционалност от към емулатора. Примерно скрипта може да включи PLL-a, да заради агент за префлашване, да го стартира, да го му подаде данни и т.н. и т.н.
Аз ти препоръчва след като си почнал да "взаимстваш" от GDB много внимателно да го разучиш. Предполагам имаш някаква документация, ако не ето ти линк http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz
Забележи, че както всяко друго нещо свързано с GNU дебъгерът (GDB) не е едно цяло, а набор от хиляди малки и полезни нещица. И функционалността е ограничена единствено от въображението на задклавиатурното устройство. Примерно аз мога да ти настроя GDB-то така, че след като се конектнеш с даден таргер да получаваш известие по SMS...
Разбира се, всичко това си има далеч по-практично приложение. Примерно аз при спиране на брейкпойнт си изкарвам най-важните неща като кой ми е текущия таск, какви таскове има активни, чакащи и т.н. Отделно си правя мои си скриптове като "canned commands" дето си ги викам от конзолата когато ми затрябват при дебъгване.
Пак чрез хукове се прави и дебъгване на мултипроцесорни системи. Примерно ако имаш две процесорчета, които от време на време си приказва по UART реално ако спреш само единия на брейкпоинт другия се шашка. Затова прихващаш брейкпоинтите и спираш и двата. А на run ги пускаш и двата.

Друг леко нестандартен "дебъгер" който си струва да разучиш е IDA PRO (DataRescue ма руснака нещо се махна). Също има ценни идеи.

Аз честно казано не знам какво те е накаро да тръгваш да правиш дебъгер. Има много добри и стабилни дебъгери, които ти би могъл да биеш по цена, но трябва да си много луд и упорит. Не е като да няма дебъгери. Има стабилни дебъгер като на IAR, които не струват като идея. Тях може да биеш с идеи...
Но за нито едно от горните две не виждам голям пазар. Просто те са обвързани с компилатори и емулатори. Ако си мислиш че някой ще си купи greenhils компилатор и ще ползва твоя дебъгер вместо тяхната тайммашинка жестотко се лъжеш.
По-скоро има голямо, ама доста голямо търсене за GNU дебъгер, защото в момента дебъгера е основното което куца при тая платформа. Просто GDB e велик като идея, но е трагедия като имплементация за АРМ. Всъщност то ядрото долу-горе работи, липсва графична среда. Insight тотално са в историята... и явно нямат намерение да продължават.
Не е задължително да правиш самия дебъгер, само графичната обвивка и нея да продаваш. Не си мисли че щом като е съвместима с GNU нещата трябва да е безплатна или опън сорс.

Миро ти е обяснил в общи линии каква е идеята - трябва да имаш (скриптова) гъвкавост да може потребителят да си подритва желязото според нуждите си. За точките на прекъсване - трябва да има поне условни такива, като условията да се задават във вид на израз (expression), примерно да ти спре някоя точка на прекъсване при "(x[5].status & 0x0FFE) == 0x07B4)". Или пък на 18-тото минаване през точката на прекъсване. Същото се разширява като имаш повече от един таргет - синхронно или асинхронно да тръгват и спират.

Аз пак ти препоръчвам да поразмислиш дали това не е работа за доста повече от един човек. А ако Ronetix имат нужда от разработчици на дебъгери защо не пробваш там (професионално)? Ако аз имах идея да правя нов (революционен) дебъгер, първо щях да огледам бая "наложили се" и да осмисля плюсове, минуси и т.н. Което отнема има-няма 3-4 години.

Вместо Qt виж wxwidgets (но аз лично от GUI не отбирам).

А пък ако още ти се играе - мога да ти дам собствен ARM дизасемблер до ARMv5, с необвързващ лиценз.

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



благодаря сърдечно за топлите думи!

сега по-същество

woody, ти казваш така:


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

за условните точки на прекъсване, може би ще мога да ги направя, но за втората (дай боже) версия на дебъгера; вече имам модул за смятане на изрази (само за подмножество на синтаксиса на C изрази), това работи стабилно, защото го направих много просто - изкопирах граматиката на C изразите, отрязах всички оператори със странични ефекти, отрязах, обаче, и деклараторите и, много важно, операторът за насилствена промяна на типове (cast) - на първо време - няма да поддържам (е, поне си признавам); после впрегнах бизона; единствената дупка, за която се сещам сега при пресмятането на изрази за началната веерсия, е, че не пресмятам коректно операторa sizeof(тъпо, но при смятане на sizeof, може да се чете паметта на target-a), няма да давам повече подробности, и без друго съм ви причинил достатъчно смях

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

http://groups.google.com/group/comp.sys ... gst&q=dbgr

(преди да разровя гугъла, писах на арм съпорта - отговориха бързо, обаче бях ги питал за arm7tdmi, не за arm7tdmi-s - моя грешка; отговорът беше да проверя разни сигнали в jtag scan chain 0, която я няма в arm7tdmi-s; тогава разрових гугъла, защото от съпорта искаха да им кажа кой съм, а аз съм никой, и нямаше какво повече да им кажа; но съм убеден, че решението, което ми бяха дали, са дивотии, ако някой го интересува, ще ги изровя от пощата тези съвети)

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



когато реших да се възправя пред целта да напиша нещо, от което да излезе нещо смислено, си дадох сметка, че съм просто човек, който знае само C, и нямам опит; затова, написах така нещата - три парчета - (1) драйвер за target-а, за момента arm симулатора откраднат от gdb, (2) ядро - да мели debug информацията за изпълнимия файл, който ще се debug-ва, и да контролира target-а, (3) потребителски интерфейс (frontend), който да дава на потребителя на дебъгера контрол върху ядрото (а следователно, и до target-а); от тези три части, многонишкова е само третата; всяка част комуникира с другата/другите през socket-и, така е най-лесно и най-добре

повече от един target е трудно, не знам как става, затова направих кода на ядрото да е реентрантен, но нишки в него не съм слагал; така - на теория - би трябвало ядрото да може да работи (не на пълна мощност) с няколко target-а и няколко frontend-а, но това е само теория; за проба на теорията, и за да намаля смеха в тази тема на форума - вчера и днес нахаках (в смисъл, сложих разни hack-ове) код в ядрото на дебъгера - с цел да видя дали наистина ще може няколко frontend-а да се вържат едновременно към ядрото; може; но - със следните ограничения - един потребител като направи нещо, това веднага го виждат и другите потребители, закачени към ядрото - например, ако потребител постъпково изпълни една инструкция, другите потребители ще видят това - без свое съгласие за такова действие, същото става ако се пълзи по стека - ако някой промени контекста, връщайки се, например, в извикваща функция, то и другите ще видят това действие - това може да е доста дразнещо; този опит ми показа, обаче, че протоколът за комуникация с ядрото не е изцяло с липса на състояние (stateless - както в gdb), това не е твърде трудно за коригиране на този етап; по-важното е, може би, че така ще мога да пусна тук, ако някой го интересува, изпълними frontend-ове, да си отпуша firewall-а, да пусна ядрото да се върти тук, вкъщи, и да може, ако някой има време и интерес, да се върже и да види как точно работи системата, но това няма да мога да го направя скоро, защото системата е твърде нестабилна, и не искам да се излагам като кифладжия (в крайна сметка, мъча се да продавам дебъгери, а не гевреци, без да искам в нито най-малка степен да обиждам майсторите на хубави и вкусни гевреци); но ако някой иска да види системата (дай боже), аз лично ще се заема да дойда и да покажа как работят нещата, дори и бирата ще купя

а за няколко target-а - имам платка за проби, но не знам какво изобщо трябва да става; ако могат колегите - кажете - какъв опит имате с проблемите за debug на няколко target-а... аз работя професионално вече доста време, 4-5 години, но нито аз, нито началниците ми, нямат опит с такава постановка; моля, споделете опит!



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

поздрави,
стоян шопов

В началото беше само дизасемблер, но после вкараха емулатори, симулатори, дебъгери и кво ли не... Не знам до каква степен си го ползвал, щото с него може и ръчно да дизасемблираш. Но предимствата му може да осъзнаеш едва ако имаш малко по-сериозна задачка. Примерно навремето трябваше да разбия един фърмуер с размер около 4 MB. Ако трябваше да го правя "ръчно" щеше да ми се разкаже играта. Щото това са няколко хиляди функции, всяка от порядъка на 100-200 инструкции, но практически между всяка функция има константи или данни и невъзможно да предвиш след като дизасемблериш една функция къде започва следващата.
Именно тук е силата на IDA и на скриптовете. Разглеждайки първите няколко функции, веднага се вижда как компилатора си оставя "отпечатъците" и вкарва еднотипни пролози във всяка функция. На базата на такива "наблюдения" си написах скриптове, които търсят нещо което прилича на пролог на функция, пробва се да дизасемблира, ако не стане продължава напред и .т.н
Идеята е, че за няколко дена написах набор от скриптове с които "дообучих" IDA-та как да дизасемблира и в крайна сметка си спестих месеци дзверене...

По подобен начин е и с дебъгерите. При нарастване на сложността става невъзможно "ръчното" дебъгване. И скриптовете и макросите стават безценни. Тая седмица оживявам един доста обемист софтуер, по-точно wap браузър и тъй като всичко сме правели сами, а и платформата е АРМ7 нямаме такива гъдели като garbadge collection ала-бала. Та голям зор се оказа да хванем къде се заделя памет без да се освобождава. Не става с дебъгване. Първото нещо дето ми хрумна е да трейсвам къде заделям и освобождавам памет:

С "-/+" освобождаване/заемане, съответно трейсвам таска, адреса от който е извикана функцията, броя на алокейтнатите поинтери и заета памет.... Хубаво, ама логът става 5-10 страници и после пада голямо дзверене да намериш "+" без "-". Отнема 20-30 мин. Докато не написах макрос на Word който търси напред "^p-", заменя ги с "^p^t-", маркира следващата дума, и я търси назад във файла. Като я намери "home" и вмъква "tab". И така в цикъл докато някое от търсенията стигне край на файла... Пускам макроса и след секунда лог-файла изглежда така:

Веднага се набива "на очи" проблемът. Съответно пиша "x/10i 0x110423 - 10" в GDB конзолата и виждам къде става заделянето...

Примерът може би не е удачен, щото макросите не са в дебъгера... Но и там биха могли да се направят. Примерно в IAR трейсването може да стане и без DCC. Вкарват си трейс функция в която слагат служебен брейкпоинт. Иначе в самата функция няма нищо. Като спре, дебъгерът проверява дали е спряло на тоя брейкпоинт и ако е той, изчита регистрите щото те съдържат параметрите на трейс функцията, съответно извлича и това което ще се логва и максимално бързо пуска процесора. Естествено подобно трейсване забавя доста, защото процесора спира и всяко спиране е поне 10-20ms. Но пък не изисква никакъв специален хардуер. И може да си гледаш трейсовете в terminal window на самия дебъгер.

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



Е от тази скромност файда няма, ясно че имаш достатъчно познания. Да не си останал с някакви илюзии за средното ниво на форума?

За изразите - не ти трябват cast-ове. Дори и в този вариант дето си избрал е прекалено мощно. А "sizeof" защо ще чете таргета - хвърляш ме в оркестъра.

Точките на прекъсване пробвай да са два типа - тези които хардуерът ти позволява (с разни компаратори на адреси/данни) с всичките им екстри, и чисто "софтуерни" точки на прекъсване. Повечето процесори имат някаква инструкция за софтуерно прекъсване, но с ARM7TDMI си прецакан и трябва да го правиш с малко хитрина в конфигурирането на единия watchpoint, като това работи само за RAM и трябва да съхраняваш инструкцията дето е била отдолу и после и нея да изпълняваш. Отделно за ARM и Thumb.



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



Не го схванах този абзац. Но навремето имах повечко свободно време и реши да си спретна собствен конзолен дебъгер за ARM7TDMI през JTAG. По едно време усетих че част от документацията е "почти" вярна, но за да проработи нещо съм въртял комбинации докато уцеля правилната. Стигнах до спиране/пускане на таргета, четене/писане на памет (и регистри съответно), дизасемблиране на код (без дебъг инфо, сурово), и вече за точките на прекъсване свободното време почна да го няма и там си остана. За мой късмет.

Също така съм забелязал че великите АРМ имат сума версии на уж едно и също и трябва да си направиш поддръжка за всичките ARM7 подварианти. Два уж еднакви може и да се различават по дължината на JTAG даннов регистър или битчетата вътре.



Първата част може да я цепнеш на две - драйвер за самия JTAG (дали е местен wiggler, или нещо remote) и за самото CPU. И ако може да са N на брой, поне като организация.

А sock-етите дали са най ще разбереш сам по-нататък.



Ти си човекът дето ще трябва да реши как да се оправя с няколко таргети - това ще ти е част от "ЗнамКак"-то (knowhow). Скалируемостта на един софтуер не я ли предвидиш в началото, после няма кърпене. Иди пипни колкото можеш различни дебъгери с железата им и събери в една тетрадка наблюдаваното. Дели после на +/- и виж какво можеш да постигнеш максимално лесно и да е най-ефективно. Че то много сложният софтуер не е добре.



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

С други думи, бих ти помогнал но нямам подръка нито хардуер нито софтуер.

За завършване да те подсетя пак да преосмислиш дали искаш да налееш много труд следващата година в нещо което е със съмнително (комерсиално) бъдеще и сложността му надхвърля няколкократно разумната като за един човек?

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

Аз бих добавил към това от woody да не се бута толкова в JTAG специфични дебъгвания,
те непрекъснато се променят с моделите, а и наистина не са особено необходими за програмиране.
Моите средства за PPC (power architecture) не ползват JTAG отвъд boundary scan въобще
(тия данни така или иначе се крият от Freescale/IBM, първите се оправдават нещо с
вторите за причината, и наистина само за тая - обща - фамилия имат скрити данни).
Но човек като прави 32 битова система все има къде да набута и някакъв дебъг монитор,
а дебъг възможностите на самото ядро - и на power, и на 68k - са толкова големи, че
човек практически никога не опира до по-засуканата им част. За ARM не знам как е,
ама ако има trace бит е лесно, а ако няма - все има я illegal opcode exception, я някакво
друго софтуерно прекъсване, през което може да се направи всичко.
Е, когато ядрото няма вградено изпълнение на една инструкция, трябва човек да
слага нещо като точка на прекъсване след всяка - и ще може да трасира само в RAM
(последното едва ли е проблем).
Разбира се да се пише дебъгер на език от високо ниво е може би най-неудобният (перверзен?)
вариант, който може да се измисли, но и това ще е едно от нещата, които може да се
научат по пътя.

Имам два въпроса:
1. Всички ARM-ове ли се програмират и дебъгват по един и същ начин?
2. Навит ли си дебъгера + програматора да бъдат плъгини за Еклипс и Visual Studio?

Не.

К*р.