Хм.. съмнявам се в ползата от тая дискусия, обесняваме си неща за които никой не е питал...

За да няма недоразумения ще повторя още веднъж:

Някои операционни системи (на практика всички големи) предвиждат концепция за дебъгване. Това означава че са предвидени известни инструменти на ниско ниво, които всички драскачи на софтуер би трябвало да познават и по възможност да ползват. Особено когато става дума за М$, където ти правиш една малка част, а проблемът може да е навсякъде в системата.
Ако всеки който пише приложение, девайс-дравер, бъс драйвер или нещо друго си прави собствена дебъг концепция като си праска printf някъде си - се получава една огромна каша от която няма излизане, защото единия не знае кода на другия и проблемите остават в ничия територия.
Има достатъчно литература и който иска може да прочете кое как става, не мисля че точно аз трябва да ги обеснявам тия работи.

Това за което ставаше дума е, че тия дебъг-концепции са създадени много преди JTAG/BDM/NEXUS и т.н. да се родят. Нещо повече, след появата им, вместо да се обновят концепциите се окастрят примерно jatg емулаторите за да бъдат съвместими със съществуващите технологии.
Най-"очеваден" пример в това отношение е комбинацията линукс-GDB-JTAG. Да не повтарям предния си пост и защо линукс се дебъгва с GDB и че GDB няма и представа какво е това JTAG. Вместо това jtag-емулаторите се представят като GDB-стъбове...

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

Това дали jtag-а изисква поддръжка от ОС-а - когато имаш jtag получаваш достъп до много неща, но това не означава непременно "дебъгване". Ако нямаш съответната дебъг информация, както и ако нямаш run-time информацията от ОС-а за да видиш на кой адрес кой DLL е сложен, какви са физически/виртуални адреси - тогава се занимаваш с "хакване" а не "дебъгване"

А това че хардуерните интерфейси за дебъгване са опция.... за мен е несериозно! Честно, не знам за контролер разработен в последните 5-10 години който да няма такава опция. Тук изключвам разни ПИК-ве - изключвам ги само щото не ги познавам

Миро, най-накрая те разбрах - ти си недоволен от това че разни OS нямат добри средства за дебъг (на самите OS). Влизам ти в положението, защото доколкото разбирам май CE те е порадвало в този аспект. Съболезнования, наистина.

Но както казах и преди, според мен всеки хардуерен дебъг предоставя различни възможности и не знам дали могат да се унифицират в някакво универсално API. Че и дали на OS-производителите (конкретно - CE) им се занимава. После наистина изпадаш в разни tool-озависими дебъг информации и кошмара става пълен.

За KGDB стъбовете нищо чудно да им е било най-лесно и бързо и затова. Сорс-кода е отворен, всеки може да допринесе да стане по-добро.
Пускал съм Linux върху embedded и съм писал драйвери без хардуерен дебъг - такъв просто нямах и нямаше как да имам.

Последното обаче си е така - debug през JTAG си е опция. JTAG е създаден и се ползва за boundary-scan. JTAG интерфейс имат не само процесори.
С две думи: JTAG != DEBUG (това се опитвам да кажа от известно време)

Човекът се оплаква от лошо затворения цикъл за дебъг на масивни OS (с кофти драйвери за нови железа) и ползване на различни 3rd party tools. И май няма да се променят много нещата.

А на последното ти изречение - умно момче си, ще си отговориш сам.