Eu tenho:

Uma placa ARM protótipo proprietária (baseada em Cortex-M3) com eCos OSA placa tem o bootloader RedBoot programadoLinha de série (RS-232)Depurador GDB para ARM (arm-eabi-gdb)O sistema operacional host é Windows / Cygwin e / ou Linux (na verdade, não importa)

Problema: O depurador do GDB não pode se conectar ao destino pela linha serial.

O que eu quero: é sniffar os pacotes do protocolo remoto do GDB para entender se o stub do GDB no alvo está ativo e operando.

Detalhes: O RedBoot tem a opção de passar o controle do alvo para o stub GDB embutido. Eu sei que o RedBoot está vivo, posso me conectar a ele e enviar comandos pela linha serial.O manual do RedBoot diz que a mudança para o stub do GDB pode ser feita digitando $ ou + símbolos (que são realmente os prefixos dos pacotes de protocolo remoto do GDB). Parece funcionar quando envio os símbolos que o terminal morre. Mas não tenho certeza se o RedBoot foi compilado com o suporte stub do GDB (não me pergunte por que :-)).

Então, quando tento conectar-me à placa com meu depurador GDB, recebo a seguinte imagem (no Windows):

(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...

A porta está correta, a taxa de transmissão também. Na verdade, a mesma saída que recebo, se eu tentar fazer o mesmo com outra porta serial que não está conectada com nada.

O que eu quero saber é se o GDB stub manda de volta alguma coisa ou não?

Intuitivamente eu pensei que provavelmente

set verbose on

ajudaria, mas o manual do GDB diz que tem um efeito muito limitado e o meu caso está além disso.

Pode ser possível compilar o depurador GDB com uma macro que habilita o registro de depuração?