Някои си имат трейс буфер, за трейс бит в смисъла на постъпково изпълнение а-ла x86 - не се сещам.
А exception-и се намират доволно, така че собствен single-step не е проблем.

ARM7 има много напушена методология за ICE, не знам спестявали ли са нещо или толкова са си могли. Откачаш ядрото от шините и почваш през boundary-scan shift регистър да си комуникираш с него. За да се изчете състоянието на регистрите примерно се инжектира фиктивна инструкция за запис на регистър в паметта (няма значение къде, ядрото е откачено) и на *правилния* клок на конвейра го изсмукваш през големия shift регистър. Същата прецизност и въртележки по shift-а за писане на регистъра. И всичкото това ти променя програмния брояч, който накрая трябва да се възстанови. Тези всичките операции ако се правят през JTAG на паралелен порт на PC на някакви десетки-стотина kHz ... не случайно е бавно.

Аз лично намирам "разнообразието" на ядра и SoC на ARM твърде необосновано, но това си е моето мнение само и на тях не им пречи да си правят пари, ама хич. Различни ядра, различни инструкции, различни тайминги, различни системни регистри (PU, MMU, т.н.), различни debug интерфейси ...

В ARM7 имаше и нещо гнило около data exception-ите, май при определени условия не можеше да се определи как трябва да се подритнат регистрите на инструкция която ги променя, за да може да се рестартира след отработване на exception-а. Веселба за мнозина, но аз нещо се уморявам от такива особености.

Не, ама по-скоро да

Разликите нямат отношение към самия дебъгер. Това че един чип има едни или повече ТАР контролери на JTAG е въпрос на конфигурация, щото е глупаво дебъгера да очаква че има само един ТАР във веригата. Регистрите които се барат също долу-горе са едни и същи, макар и да има промени според версията...
Програмирането също се прави по еднотипен начин - качва се агент, подават му се данни и той ги пише... В мнооого редки случаи при АРМ ще пишеш директно, но дори и тогава емулаторите оставят вратичка да си дефинираш собствени JTAG последователности....

Всъщност грешката на Шопов че изобщо прави и тия неща - те не са част от дебъгера. Един дебъгер трябва да има интерерфейси за определени емулатори. Примерно JLINK, RDI, OpenOCD и т.н.

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

доколкото помня от беглите ми разглеждания, arm7 и arm9 са много сходни, разлика имаше в дължината на instruction регистъра в jtag-a, arm9 имат подръжка за single-step и vector-catch (да се спира процесора, когато се извика някой от векторите на прекъсвания/изключения), арм9 може да каже еднозначно причината за спиране на процесора, за арм7 (преди бях писал - много рядко, ако човек има много лош късмет) - причината за спиране (а оттам и процедурата за възобновяване на изпълнението на ядрото) може да не е еднозначно ясна

за арм10 и арм11 не знам нищо, но подозирам, че ще може лесно да се преработи кода за арм9; за xscale трябва да се зареди софтуерен агент за целите на дебъга

в cortex m3 е по-различно, там има възможност и за т.нар. sw (serial wire) jtag - jtag по два пина, някаква серийна връзка; и тук като цяло нещата не би трябвало да са много трудни да се напишат, една седмица си поиграх, и започнах да пиша драйвер за кортекс м3 - но засега имам само спиране на ядрото, четене на регистри (и на памет, ако си спомням вярно)

но като цяло - съгласен съм с miro_atc - написването на target driver, ако човек знае какво прави, може да стане за около две седмици; всъщност съм предвидил модул за флашване, не знам дали съм обяснил правилно - самият драйвер за клатене на хардуера не е част от ядрото на дебъгера; на ядрото му се казва къде се намира драйвера, който клати хардуера (ip адрес + номер на порт), оттам нататък всички заявки - четене/запис на регистри/памет и т.н. се правят по стандартно дефиниран интерфейс подобен на gdb remote serial protocol, пускани през socket към машината, където се търкаля драйвера (не помня защо точно не ползвам gdb remote serial protocol, май бях възприел някои архитектурни решения, които правят конвертирането от/към gdb remote serial protocol нетривиални, и оставих това за после); примери - нищо не пречи, този драйвер да е в някой embedded ethernet debugger (с един колега мислим да направим такова нещо като имаме време, което може и да значи - никога), или да е на локалната машина, или да е link-нато директно към ядрото; същото важи и за frontend-а

за илюстрация - долу прилагам два source файла - target-img-load.c (ползва се за флашване), и core-access.h - съдържа декларацията на интерфейса към target драйверите; ако някой разглежда тези файлове, следва да се имат впредвид следните неща:
(1) тези файлове са в голяма степен недовършени
(2) файл target-img-load.c съдържа голямо количество коментари, в които има много повторения; идеята коментарите да са толкова много е после лесно да се изгенерира сносна документация в doxygen формат; някъде не са много на ниво коментарите, защото всичко това го правя вкъщи, след работа, като нерядко ми остават едва 4-5 часа сън (но днес след малко лягам); в последно време съм претоварен в службата, но вечерите ще се мъча да отговарям, ако има интерес към темата
(3) донякъде файл core-access.h прилича на rdi арм интерфейса, не помня кой точно файл (сорсовете са в гдб), това е защото отначало исках да почна от rdi драйвер, който да продавам с някакъв custom jtag интерфейс, после реших да не се занимавам с това; ако някой го интересува - мога да му помогна ако иска да пише rdi драйвер - това всъщност актуално ли е вече, интерфейсът е много стар, помня, че като почвах - закачах се към IAR - положението беше плачевно - IAR-ът беше страшно бъгав, викаше функциите на rdi драйвера в прозиволен ред - напр. първо викаше някаква ф-я за четене на параметри, и едва после викаше инициализацията на драйвера - ужасна работа; докарах го до там, че успях да вържа armulator ядрото към IAR през rdi, но по-нататък не съм правил нищо, защото откъм хардуерната страна на нещата съм много неподготвен, а не намерих никой, който да иска да ми помогне...

за потребителския интерфейс - ами да, много ще е хубаво да са plugin-и, всъщност, това мисля, че не трябва да е много трудно; но аз нямам времето да го направя, затова и screenshot-овете, които пуснах, изглеждат толкова грозно; сега ще опиша по-подробно защо мисля, че не трябва да е много трудно да се направят някакви plugin-и
комуникацията frontend - debugging engine - target access driver става така -> цялата комуникация е през socket-и, форматът на заявките от frontend-а към ядрото (debugging engine) е във формат на dbx (http://docs.sun.com/app/docs/doc/819-5257/blatm?a=view), прецених, че после ще е по-лесно да се опишат само несъвместимостите, отколкото да се пише ръководство; форматът на заявките от ядрото към драйвера за клатене на хардуера е в прост текстов формат, лесен за parse-ване; драйверът връща информация на ядрото също прост текстов формат, лесен за parse-ване, ядрото връща на frontend-а текстов формат, лесен за парсване и съдържащ много информация, за да става визуализацията лесно (с малко код); пример:

(1) потребителя иска да види регистрите, натиска някакъв графичен бутон, и кода за обработка на бутона изпълнява следния код:

comm е комуникационния обект за връзка с ядрото
също, може потребителя директно да пише в някакъв конзолен прозорец командата regs - това е dbx командата за четене на регистри
(2) ядрото отработва заявката, и праща заявка към драйвера за достъп до хардуера:
REGS_READ(0xffff)
0xffff е битова маска - кои регистри да се четат; форматът лесно може да се смени ако се окаже, че е неподходящ
(3) драйверът отработва заявката и връща на ядрото резултат:
GEAR_ERR_NO_ERROR,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
(4) ядрото отработва отговорът и връща на frontend-а:
ERRCODE=[0,""],REGLIST,("r0" = 0x00000000, "r1" = 0x00000000, "r2" = 0x00000000, "r3" = 0x00000000, "r4" = 0x00000000, "r5" = 0x00000000, "r6" = 0x00000000, "r7" = 0x00000000, "r8" = 0x00000000, "r9" = 0x00000000, "r10" = 0x00000000, "r11" = 0x00000000, "r12" = 0x00000000, "r13" = 0x00000000, "r14" = 0x00000000, "r15" = 0x00000000, "pc" = 0x00000000, "cpsr" = 0x000000d3, "spsr" = 0x00000000, )

забележете, че в точки (2) и (3) форматът трябва да е нарочно много прост, за да може да се parse-ва на ръка, понеже е възможно този код да е в някой embedded target, и ресурсите да са ограничени

за точка (4) - форматът е нарочно многословен; друг пример, за команда where, ядрото връща на frontend-а (малко съм вкарал интервали и табулации, за да е по-четливо):
ERRCODE=[0,""],
BACKTRACE,
(
[PC_ADDR = 0x40000100, COMP_UNIT = "test_0.c", SUBPROGRAM = "main", SRCFILE = "/home/shopov/src/gear-201108/engine/target_test/test_0.c", SRCLINE_NR = 19, ],
[PC_ADDR = 0x00000000,],
)

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


това по същество е най-прост списък със стековите рамки на извикване; това, мисля, трябва да е ясно как да се визуализира лесно, в eclipse например, но аз с eclipse досега не съм имал време да се занимавам

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

все още нямам желание да обнародвам кода, искам първо да завърша нещата, живот и здраве - дано и това стане скоро :)

поздрави!

Малко изненадващо ми е това, че нямат t бит някъде (предполагам, че в x86 е като в 68k и power -
ако тоя бит е вдигнат изпълнява една инструкция и след това отива в trace exception).
Намирисва ми (отдалеко, не знам детайлите) - на мърлява работа, толкова не са могли
да си доправят ядрото.

Последно правих дебъгер без такъв бит май за 5420 DSP-то, там един таймер ми влезе
в работа за single step изпълнения. Вече не помня подробностите, ама имаше не малко
фокуси май - с тия подробности около pipeline-а, дето ги има и може би още нещо,
ама стана лесно доколкото си спомням (преди бая години беше, 2001 май).



Ами JTAG по някакви стари спомени се клочи до към 10-ина MHz; цялата тая
боза, дето я описваш, явно няма как да не е бавна. Не знам дали бих имал търпението
да я чакам, ако забелязвам времето от натискане на "N" (next instruction) до виждане
на регистрите след това вероятно бих го захвърлил и бих направил някакъв
по-софтуерен дебъгер да си върша работата както винаги досега.

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



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



Е то това звучи като неизползваема работа за мене, ако има ситуации, дето не можеш да контролираш
ядрото без JTAG. Ама аз и без друго не ги и ползвам, де - и май не им се пише да почна да ги
ползвам, колкото повече чувам отстрани за тях, толкова по-мърляви почват да ми изглеждат.

Изказваш се леко неподготвен... В АРМ няма един бит, има цял дебъг контролер, който е позициониран като коопроцесор. Не е част от ядрото поради много и добри причини.
Първо колкото по-малко ненужни работи има в едно ядро, толкова по-бързо и предсказуемо е то. Второ на дебъг подлежи не само ядрото, ами и другите коопроцесори и периферии. Примерно, ДМА-тата също правят аборти. Трето, всичко при АРМ е на модулен принцип и както всички други модули производителят на чипа може да конфигурира. Примерно някой може да сложи ЕТМ (ембеддед трейс) други може да си го спестят. Изключение е само ядрото, което е твърде сложен "модул" и всеки избягва да бъзика.

Дебъг архитектурата на АРМ предлага halting и monitor дебъг режими. Мониторният режим е "аналогът" на Т-бита, само че доста по-развит. Вместо един бит имаш набор от регистри в които може да задаваш кога да спира и да прави ексепшън. Примерно може да си слагаш уатчпоинотве вместо като хамалин да анализираш всяка една инструкция кво прави.
Все пак говорим за контролери и real time приложения, които НЕ МОЖЕШ да дабъгваш с твоя Т-бит...
Не знам доколко се поддържа мониторния режим при АРМ7, може и да не поддържа. Със сигурност го имат 9-ките щото операционите, особено М$-те го изискват *задължително*. Но при 7-ците файда от подобни монитори няма абсолютно никаква... То ако имаш работещ монитор, значи половината от дебъгването е минало... А междувременно докато го подкараш може да дебъгваш самия монитор с халт режима и външния дебъг интерфейс

Ми колко подготвен да бъда, поне на две места споменах, че не познавам ARM и коментирам
само каквото съм видял отстрани.



Това достъпно ли е от ядрото - или само през JTAG? Ако е второто, приказките ми
за мърлявост си остават в сила. Ако е първото, вземам си ги назад.



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



Е то ако няма работещ монитор (дебъг мониторен софтуер, с който си говориш през някакъв интерфейс, например
сериен терминал?) какво има.

Разбира се че е достъпно, то иначе що за монитор ще е Казах че е имплементирано като коопроцесор, ядрото си има инструкции за работа с коопроцесори и техните регистри...




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

С две думи имаш контрол върху ядрото и си застанал между него и всичко останало. Макар директно да не можеш да адресираш нищо по шините, ти имаш контрол върху ядрото и може да го накараш то да направи всичко което искаш...

Мяркал съм до 25 MHz (не непременно ARM-ове).

Забележимо бавно е само ако интерфейсът е тип "хоби" - прост буфер на паралелния порт и PC-то клати битове на килохерци (под многозадачна ОС). Един интелигентен интерфейс с макро команди на ethernet/USB (за повечко $$) оправя положението.



Горе-долу, търсили са модулен вариант така че дебъг частта да може да липсва. Ама и не съм очарован.



Коефицентът на участие на техническите достойнства в общата формула на успеха е доста малък. Силиконът и т.н. са само средство за правене на неприлично големи $$, не цел.



Това важи за самото ядро, без JTAG. Тоест ако има MMU (ARM 720) и менажера на паметта трябва да направи swap-in на някоя страница виртуална памет и да рестартира фалиралата инструкция. Имаше нещо неопределено май дали някои регистри са били променени или не.

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

Според слухове, Срансунг (Samsung) бяха чоплили нещо и пуснали ARM9 на 400 MHz, при положение че ARM-овското е до 200 MHz. Съответно ARM ги подгонили за неспазване на лицензионните съглашения.

Погледнах току-що чаршафите - мониторният режим на ARM7 позволява да влезеш в exception единствено по адрес, без range-ове и конкретни данни. Аз го разбирам като да не можеш да си слагаш софтуерни точки на прекъсване на повече от две места. Дори и постъпковото изпълнение става много рошаво.

Да рошово е... и то не само в мониторен режим. Изисква се доста логика, особено ако не си в монитор, ами с външен JTAG емулатор където освен всичко останало всяка операция трябва да я съобразяваш с конкретната JTAG верига и според броя на устройствата да вкарваш и изкарваш битове... Но не бих казал, че това има някакво значение. Примерно при PEEDI много от нещата се правят чрез FPGA и JTAG клока бачка до над 30MHz и просто няма как да стане по-бързо, щото фпга-то си е фпга и никъде не се замисля... Но въпреки това ако сравниш PEEDI с едно OpenOCD дето се клати софтуерно през някакъв FTDI разлика в скоростта на дебъгване няма съществена. Причината е много проста - за постъпково изпълнение или за влизане/излизане от брейкпоинт ти няма как да разбереш дали е станало за 1 или за 100ms. И това че PEEDI е примерно 100 пъти по-бързо няма как да го забележиш.
А пък при интензивните операции с данни, архитектурата е такава че само пращаш и получаваш и там няма логика. Трансфера общо взето е на всеки 33 клока имаш 32 бита данни и дори и софтуерните емулатори успяват някак си да бълват данните на прилична скорост. Поне за ARM7 софтуерните емулатори не дразнят, особено ако се флашва. Разликата става видима едва ако почнеш да качваш големи имиджи като лайнукс.

Та с две думи исках да кажа че софтуерните сложнотии не са проблем. АРМ7 си се дебъгва... за нас няма грижи, само за такива като Шопов
Иначе монитори за АРМ7 аз не съм видял някой да ползва. Едно че няма да са толкова прости, друго е че ако имаш JTAG не ти трябват. Аз съм се замислял евентуално някой ден да направя нещо подобно, щото в производството много обичат да пестят от JTAG конектори.... Ама няма да е скоро, може би никога няма да го направя

сега успях да го видя по-подробно това - аз не пиша на високо ниво (под високо ниво разбирам c++, java, разни скриптови езици - напр. perl, python(за последните два може и да бъркам, т.е. да са компилирани езици)), пиша на c; какво искаш да кажеш, tgi - кое е неудобното да се пише дебъгер, да речем, на по-високо ниво - напр. c++ - опитах се за визуализация в дебъгера да ползвам c++, и всъщност работи много удобно, макар и да не съм много навътре с възможностите на този език

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

Шопов, не четеш редовно форума, затова не знаеш кое му е неудобното. Не си ли виждал листинга на прочутия хард диск с прочутите 40 годишни асемблерски сорсове, дето заемали 30GB ( по 750ml на година ! ) ?? Дори не знаеш елементарни неща, че например не бива да използваш готов софтуер като CAD програма например ?? Трябва да си драснеш собствен визуален редактор на асемблер ! Не бива да се изполвзва нещо различно от асемблер, не бива дори да пишеш на готова ОС, ами трябва да си направиш твоя, щото от къде да знаеш как работи готовата. Всичко трябва да си правиш сам, дори и влаковете да си взривяваш сам като в доброто старо сибирско време. А и HTML-то с какво мислиш го четем ? Позна, пак със собствен асемблерски код ! Ако се отчетеш с такава дейност, вервай ми, немедленно ще бъдеш похвален А ти си тръгнал тук някакъв ARM дебъгер да ковеш, при това на Ц, просто твоето мирише на еретизъм отдалеко

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

А бе Пи, къде го прочете това за 30-те G? Да не визираш моите 30-ина М (ама те не
са 40 годишни, де само 15-на са и то най-старото в тях, та сигурно нещо друго имаш на ум?).

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