Questions about OpenOCD's GDB implementation

Development Boards MicroMod
1

Q1) The GDB remote protocol has a reset-target message, but the GDB protocol docs say that it is deprecated, and OpenOCD doesn’t implement it. Omitting a reset command probably makes sense if you are debugging a remote Linux box, but it seems very odd if you are debugging an embedded target: how do you ensure that all the peripherals are in their reset state? Currently, I use qRcmd to send a reset command to the OpenOCD TELNET interface, but why not implement ‘r’?

Q2) OpenOCD’s GDB server doesn’t return errors (Exx) if you attempt to read or write memory locations that cause an abort, even though the actual read/write call returns an error. Some messages, such as register read when the target is running, cause the server to exit. Are these design decisions based on how GDB uses the server, or just quickly-written code? I would be happy to add “complain and keep going” code to OpenOCD, but I don’t want to waste the time if there is a reason why this shouldn’t be done.

2

Hi,

the GDB never sends the ‘r’ package, at least I’ve never seen it, and I don’t know which GDB command could possibly trigger an ‘r’ or ‘R’ packet. As I understand it, GDB doesn’t have a concept of a target reset. If I want to reset the target from within GDB, I use “monitor reset” as you do with the qRcmd.

The GDB server code isn’t as robust as I’d like it to be, but it works reasonably well with current GDB clients. For example if the GDB ever requested a register while the target is running, we’re in so much trouble anyway that it doesn’t matter if the server exits.

Regards,

Dominic