Protocolo remoto do GDB: como analisar pacotes?
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?