Пошаговый отладчик пользовательской программы, как это делается? Опции

[TMX]

Возникла задача разработки транслятора технологического языка программирования. Требуется, чтобы была возможность пошаговой отладки на целевом устройстве.
Как это делается вообще?
Задача выполняется на ARM (LPC или SAM7, скорее первый).
Основная проблема - как заставить ядро ARM выходить в обработку исключения при достижении заданного адреса в пользовательской программе.
Пока решения следующие (в скобках - пятибалльный показатель уверенности в результате):
. Заливать отладочный вариант проги со SWI после каждой макрокоманды(4).
. Вызывать в цикле пользовательские команды в виде отдельных функций по ссылке, с выходом в проверку после каждого вызова(5+).
. Ставить внешний Atmega8, который буде рулить JTAG-ом(2).
. Не сбрасывать флаг прерывания, чтобы проц каждый раз заходил в обработку при исполнении очередной команды(1).

[zltigo]

Как это делается вообще?

Читаем последние главы мануала на LPC посвященные поддержке разных способов отладки.
А вообще-то этот раздел DSP посвящен.

[DASM]

Как это делается вообще?

Читаем последние главы мануала на LPC посвященные поддержке разных способов отладки.
А вообще-то этот раздел DSP посвящен.

Как это ? Уже DSP ???: :-O

[makc]

Как это ? Уже DSP ???: :-O

Это я тут подшаманил - перенес тему в раздел ARM, где ей и место.

[TMX]

Читаем последние главы мануала на LPC посвященные поддержке разных способов отладки.

Ну и читайте на здоровье...
Я эти главы прочитал: все эти способы отладки, насколько я понял, требуют внешнего JTAG, см. рис. 40, 43, 44.
А это для моей задачи избыточно.
Мне достаточно, чтобы только код юзера исполнялся. Т.е. у меня есть возможность вставлять в его код отладочные строки т.п. Просто интересует, как это делается обычно.

[makc]

Читаем последние главы мануала на LPC посвященные поддержке разных способов отладки.

Ну и читайте на здоровье...
Я эти главы прочитал: все эти способы отладки, насколько я понял, требуют внешнего JTAG, см. рис. 40, 43, 44.
А это для моей задачи избыточно.
Мне достаточно, чтобы только код юзера исполнялся. Т.е. у меня есть возможность вставлять в его код отладочные строки т.п. Просто интересует, как это делается обычно.

Когда я столкнулся с подобной проблемой отладки у меня не было JTAG'a, да и времени его делать тоже. Проштудировав документацию я пришел к тому же самому выводу - отладка без внешнего JTAG'a довольно большая проблема, если только не использовать отладочную версию прошивки/программы и т.п. После этого я сделал себе макросы на C, которые в случае компиляции отладочной версии прошивки в критических местах выдают отладочную информацию в UART. Мне этого хватило...

PS: Я одного не могу понять: добавить в ядро ARM отладочные регистры, с помощью которых можно было бы программно устанавливать точки останова по нескольким условиям (наподобие того, как это сделано в IA32/IA64) совсем не большая проблема. Почему этого не сделали? Единственное объяснение - узкая специализация ядра на встраиваемые применения, где можно и нужно с точки зрения разработчиков отлаживаться с помощью JTAG'a и ему подобных средств внутрисистемной отладки.

[zltigo]

Ну и читайте на здоровье...

Плохо читали, ибо сложно не понять, что существует аппаратная поддержка BreakPoint, RealMonitor и Angel, реализующийся, например на RS232.

PS: Я одного не могу понять: добавить в ядро ARM отладочные регистры, с помощью которых можно было бы программно устанавливать точки останова по нескольким условиям (наподобие того, как это сделано в IA32/IA64) совсем не большая проблема. Почему этого не сделали?

Почему не сделали - сделали:
The EmbeddedICE logic contains 16 registers. The ARM7TDMI-S debug architecture is described in detail in "ARM7TDMI-S (rev 4) Technical Reference Manual" (ARM DDI 0234A) published by ARM Limited and is available via Internet at http://www.arm.com.

[TMX]

Возможно, я не совсем правильно спросил,
добавлю:
изделие - что-то вроде технологического контроллера. Не думаю , что имеет смысл давать наладчику в руки JTAG и компилятор С.
В F2MC я использовал для похожей задачи специальные прерывания по выборке заданного адреса.
В AVR - не сбрасывал в прерывании флаг.
Здесь я думаю сделать так:
сделаю трехадресный ассемблер, т.е. программа будет в виде таблицы структур - указатель на функцию команды, операнды и между вызовами буду проверять текущий адрес.
Просто хотелось узнать, может еще проще можно сделать...

[TMX]

Плохо читали, ибо сложно не понять, что существует аппаратная поддержка BreakPoint, RealMonitor и Angel, реализующийся, например на RS232.

Возможно я плохо читал, но я не понял, как получить доступ к регистрам управления из программы.
Буду благодарен за подсказку в какой конкретно регистр писать адрес останова?
В сущности, куда записывать, чтобы программа вылетела по Prefetch Abort?

[zltigo]

В сущности, куда записывать, чтобы программа вылетела по Prefetch Abort?

Забавно, но похоже действительно со сторны AMBA нет доступа :-( Когда несколько месяцев назад начинал прочитал, отметил, что для ETM специально отмечено отсутствие со сторны AMBA, ну а для
EmbeddedICE нет. Хотя надо еще покопать....

[makc]

PS: Я одного не могу понять: добавить в ядро ARM отладочные регистры, с помощью которых можно было бы программно устанавливать точки останова по нескольким условиям (наподобие того, как это сделано в IA32/IA64) совсем не большая проблема. Почему этого не сделали?

Почему не сделали - сделали:
The EmbeddedICE logic contains 16 registers. The ARM7TDMI-S debug architecture is described in detail in "ARM7TDMI-S (rev 4) Technical Reference Manual" (ARM DDI 0234A) published by ARM Limited and is available via Internet at http://www.arm.com.

Цитата из этого документа:

The ARM7TDMI-S processor EmbeddedICE-RT macrocell module provides
integrated on-chip debug support for the ARM7TDMI-S core.
EmbeddedICE-RT is programmed serially using the ARM7TDMI-S processor TAP
controller. Figure 5-5 illustrates the relationship between the core, EmbeddedICE-RT,
and the TAP controller, showing only the signals that are pertinent to
EmbeddedICE-RT.

Тут ясно написано, что для программирования EmbeddedICE-RT используется TAP. Т.е. из самого отлаживаемого ядра процессора добраться до требуемых регистров EmbeddedICE не получится. Или я чего-то не понимаю?

[zltigo]

Возможно, я не совсем правильно спросил,
добавлю:
изделие - что-то вроде технологического контроллера. Не думаю , что имеет смысл давать наладчику в руки JTAG и компилятор С.

Совсем не понятна функция 'наладчика'. И совсем не понятно зачем ему "компилятор C".
JTAG для упрощения себе жизни - да. Ну и на него либо свою специализированную оболочечку через
RDI, например, либо простенький отладчик, типа JLink.

[psL]

обычно брекпоинт в мониторных системах представляет собой програмное прерывание - ловушку, по которому программа вываливается в отладчик, т.е. код операции пользовательской программы меняется на програмное прерывание, а сам код запоминается в некоторой структре. Вываливаемся в отладчик->смотрим что нужно->выполняем замещенный код->продолжаем выполнение программы.

Если я правильно понял задачу, в Вашем случае можно перед каждой интерпретируемой командой поставить ловушку, в обработчике которой анализировать признак выполнения по шагам.

[zltigo]

Тут ясно написано, что для программирования EmbeddedICE-RT используется TAP. Т.е. из самого отлаживаемого ядра процессора добраться до требуемых регистров EmbeddedICE не получится. Или я чего-то не понимаю?

Я уже объяснил, что ввело меня в заблуждение :-(

[makc]

В сущности, куда записывать, чтобы программа вылетела по Prefetch Abort?

На сколько я понимаю, исключение Prefetch Abort генерируется только в случае, если производитель процессора с ядром ARM использовал сигнал ABORT:

An abort indicates that the current memory access cannot be completed. It is signaled
by the external ABORT input. The ARM7TDMI-S checks for the abort exception at the
end of memory access cycles.

Иными словами, если контроллер памяти не дает сигнала ABORT, то пишите - не пишите, а исключения не получите.

Тут ясно написано, что для программирования EmbeddedICE-RT используется TAP. Т.е. из самого отлаживаемого ядра процессора добраться до требуемых регистров EmbeddedICE не получится. Или я чего-то не понимаю?

Я уже объяснил, что ввело меня в заблуждение :-(

Извиняюсь, пока я тут писал свой ответ, Вы успели ответить раньше.

обычно брекпоинт в мониторных системах представляет собой програмное прерывание - ловушку, по которому программа вываливается в отладчик, т.е. код операции пользовательской программы меняется на програмное прерывание, а сам код запоминается в некоторой структре. Вываливаемся в отладчик->смотрим что нужно->выполняем замещенный код->продолжаем выполнение программы.

Если я правильно понял задачу, в Вашем случае можно перед каждой интерпретируемой командой поставить ловушку, в обработчике которой анализировать признак выполнения по шагам.

А что делать если код исполняется из FLASH? Его модифицировать "на лету" не получится. К тому же я слабо себе представлю, как будет работать такая подмена в случае конвейера ядра ARM. Ведь возврат будет происходить не на подмененную инструкцию, а на следующую за ней. Т.е. при подмене обработчик исключения должен будет обработать подмененную команду самостоятельно, а если она работает с памятью по относительному смещению (такое, кстати, бывает довольно часто)?

[zltigo]

А что делать если код исполняется из FLASH? Его модифицировать "на лету" не получится.

Насколько я понял, у автора речь идет не о командах контроллера а 'командах-подпрограмах'.
Там можно и намертво замонтировать вызов точки трассировки. Если подпограммы длинные, то можно
попробовать манипулировать разрешением/запрещением какого-либо внешнего источника прерывания,
в обработчике которого анализировать и держать_и_не_пущать пока источник прерывания снят
не будет на время достаточное для вваливание в следующую 'команду'. Кстати, сам обработчик
прервывания можно на ходу переназначать, если нужно.

[psL]

А что делать если код исполняется из FLASH? Его модифицировать "на лету" не получится. К тому же я слабо себе представлю, как будет работать такая подмена в случае конвейера ядра ARM. Ведь возврат будет происходить не на подмененную инструкцию, а на следующую за ней. Т.е. при подмене обработчик исключения должен будет обработать подмененную команду самостоятельно, а если она работает с памятью по относительному смещению (такое, кстати, бывает довольно часто)?

Все правильно говорите. Но:
Возможно я не правильно уловил суть вороса - помоему человеку нужна отладка в интерперетаторе, а не эмуляция отладки самого интерпретатора через JTAG, которая, насколько мне известно, невозможна.

[makc]

А что делать если код исполняется из FLASH? Его модифицировать "на лету" не получится. К тому же я слабо себе представлю, как будет работать такая подмена в случае конвейера ядра ARM. Ведь возврат будет происходить не на подмененную инструкцию, а на следующую за ней. Т.е. при подмене обработчик исключения должен будет обработать подмененную команду самостоятельно, а если она работает с памятью по относительному смещению (такое, кстати, бывает довольно часто)?

Все правильно говорите. Но:
Возможно я не правильно уловил суть вороса - помоему человеку нужна отладка в интерперетаторе, а не эмуляция отладки самого интерпретатора через JTAG, которая, насколько мне известно, невозможна.

Да, тут есть неоднозначность. Автор написал:

Основная проблема - как заставить ядро ARM выходить в обработку исключения при достижении заданного адреса в пользовательской программе.

Я интерпретировал "пользовательскую программу", как программу для поцессора ARM, т.е. сам интерпретатор. Т.к. для интерпретируемого кода, в принципе, можно написать эмулятор на PC и это в ряде случаев будет гораздо проще...

[TMX]

Большое спасибо всем ответившим, не имел доступа к интернету, поэтому не участвовал в обсуждении
Резюме: делаю язык линейных инструкций типа IL, оформляю их в виде подпрограмм, которые вызываю по таблице структур, содержащей указатель на подпрограмму и параметры, эта таблица и является программой. Функции вызываются по указателю в цикле в фоновом процессе, после каждого вызова функции-команды вызывается функция-отладчик.

Я интерпретировал "пользовательскую программу", как программу для поцессора ARM, т.е. сам интерпретатор. Т.к. для интерпретируемого кода, в принципе, можно написать эмулятор на PC и это в ряде случаев будет гораздо проще...

С эмулятора на PC (LabWindows) я и начну