Как это выглядит в протоколе remote-target я не скажу, потому что мне никогда в голову не приходило попробовать приконнектится telnet'ом к удалённому gdb. Но в command-line можно использовать команду info registers или что-нибудь вида "print $rax". А когда мне надо посмотреть дамп памяти, я обычно делаю это командой print с приведениями типов, примерно так: "p/x (*(unsigned*)$rsp)@256". p -- это сокращение команды print, /x говорит о том, что я хочу видеть числа в hex'е, в скобочках стоит чисто C'шное выражение, преобразующее число из $rsp к типу unsigned*, и затем разадресовывающее получившийся адрес, а @256 говорит о том, сколько элементов надо вывести.
Ко всему этому в gdb есть команды stepi и nexti позволяющие трейсить программу по одной инструкции. И, наконец, gdb'шная команда break принимает в качестве аргумента адрес. Чуть не забыл, есть ещё команда disassemble, которая может кусок памяти перевести в ассемблерные мнемоники. То есть в gdb есть всё, чтобы отлаживать голый бинарь без какой-либо отладочной информации.
Не скрою, что gdb весьма неудобен для отладки при отсутствии отладочной информации, если при source-level отладке gdb вполне можно использовать через командную строку, то при "бинарной" отладке уже всё становится существенно хуже.
Но это же нам не очень важно: планов приделывать отладчик с command-line интерфейсом никто не строит. Нужен фронтенд, и есть у меня подозрение, что написать фронтенд к gdb не сильно-то и сложнее, чем непосредственно к симулятору. Но в случае с сорц-левел отладкой, этот фронтенд будет иметь массу вкусностей, типа вывода думпа памяти не в хексах, а примерно в таком виде:
И для этого фронтенду вовсе не обязательно понимать, что такое C'шная структура, и каковы особенности вывода на экран значения типа char*, потому что этим всем может заниматься gdb, а фронтенду останется лишь получать готовый результат в текстовом виде.
C восьмибитным AVR он справляется. С виртуальным. С simulavr.