GDB-Server vCont command handling

Question

We're using a custom chip from a certain supplier. The supplier also provides a custom compiler and related tools (based on GCC) including an emulator for the chip, which supports symbolic debugging using eclipse CDT via GDB to the emulator.

The GDB debugging is based on a modified gdb.exe talking to a GDB-Server stub, both implemented by the supplier. The communication between eclipse CDT and the modified gdb.exe is naturally based on MI protocol, and between the modified gdb.exe and the GDB-Server stub is based on RSP protocol as can be expected.

We've implemented a simulator for this custom chip to avoid over-reliance on the emulators for non-hardware specific debugging. This simulator uses the same ELF file produced by the compiler that is used with the emulator. To keep matters simple we've implemented the GDB-Server stub inside our simulator with the intention it can be a drop in replacement for the emulator.

We have the basics working but have run into an issue on handling vCont commands. Since we don't need multi-threaded support we don't really need to support the vCont commands. So, in response to the QSupported command, I respond with a vContSupported- flag.

Then, after continuing from a breakpoint, when I get a vCont? query, to which I reply with an empty response (the RSP packet +$#00) to indicate (according to the documentation) that "the ‘vCont’ packet is not supported.".

Despite this I still, in the next command, receive a vCont;s:0;c:0 command. I don't know how to handle this command?:

• Does it indicate a 'step' followed by a 'continue' (on the default thread)? How is that different from simply 'continue' i.e. why not just vCont;c:0 ?
• Why do I still get a vCont command despite the negative vContSupported flag and empty response to vCont? just prior to this command?

Note that, in eclipse CDT (with 'verbose console mode'), there are 2 identical warnings in the console: "warning: Invalid remote reply:", in response to the 2 vCont commands, but no other error details of what the error is. So it may be that their modified gdb.exe does not like the empty reply and hence continue to output vCont commands, rather than the default individual 's', 'S', 'c' or 'C' commands.

Also note that I don't have access to the sources of the supplier's modified gdb.exe or GDB-Server stub - in fact they have been totally unresponsive to any queries on how their GDB-Server stub handles this.

Has anyone experienced anything similar with vCont commands? How should you handle this?

Answer 1

Based on the recommendation from Andrew to set debug remote 1 from his comment above I at least managed to figure out to which responses the warnings are applying.

That helped to, after some more researching/googling, figure out that the vCont;s:0;c:0 i.e. “step then continue” behavior is typical for software breakpoints:

• Restore original content when execution is halted (pause or breakpoint hit).
• When resuming (continue):
  • Execute one step to go beyond current breakpoint, since breakpoints stops just before the line/instruction of the breakpoint is executed.
  • Change memory content/registers/etc according to breakpoint instruction after execution.
  • Then continue execution.

So instead of an individual s command followed by an individual c command to achieve the above, you now get a kind of compound vCont;s:0;c:0 command, which includes the applicable thread to apply it to as well. The thing to note is that the reply to the vCont;s:0;c:0command is the reply to the final c:0 sub-command - you swallow the result of the s:0 sub-command.

I still don't know why the empty response to a vCont? command is ignored though. I only have a single thread in my target and, prior to this, in a response to a qC thread, responded with qC0- indicating "no particular thread". In fact, with the above debug setting, eclipse CDT trace shows:

Sending packet: $vCont?#49...Ack
Packet received: OK
Packet vCont (verbose-resume) is supported

For some reason it ignores the empty reply (meaning "the ‘vCont’ packet is not supported."), and reverts to "(verbose-resume) is supported".

But ok, since it seems I have to support vCont....commands, I'll just do so.