RFC: New Proposal for a Debugger

[Richard-Stump]

Motivation

There exists a group of PROS users who want better debugging features for the PROS ecosystem. Currently users must print their variables to the terminal or screen in order to debug their programs. There is also plans to add interactive stack traces to the cli to assist with finding memory errors. Adding more in depth debugging support would further ease debugging PROS software.

JINX

JINX was the original idea to add a debugging system to PROS. JINX was planned to use 3 main components to provide debugging features:

1. A set of PROS functions and a never-ending task that reads commands from a serial device
2. A webpage the user interacts with
3. A python middleman that mediates between the brain and webpage

The JINX development guidelines provide a little more detail on the implementation. Users would need to register objects/variables to the system before JINX could see it. The 3 components would then communicate commands/objects back and forth over a serial device to provide debugging features.

New Implementation

My new proposal now consists of four main parts:

1. A kernel task that parses GDB remote serial protocol commands and responds with requested results
2. A GDB process connected through the PROS terminal or a generic serial device.
3. The PROS CLI providing an interface between the VSCode extension and the GDB process.
4. The VSCode extension to provide a graphical interface for users

GDB Remote Debugging Serial Protocol

The original plan for JINX involved creating a protocol that the python middleman and kernel would use to communicate. Instead of designing, implementing, and testing a new protocol, utilizing an existing one would be preferable. GDB already provides a protocol for remote debugging, and using it would allow users to use GDB directly and provide the host-side implementation for us. As for the kernel side, we would need to implement a stub that implemented the GDB remote serial protocol. I'm sure we could find an existing stub and bring it into the kernel.

CLI Middle Man

The CLI would sit between the VSCode extension and the GDB process to mediate communications between the two. This component may not be necessary, but this is included here for the sake of discussion. The CLI could provide a better interface to GDB, but if this is deemed unnecessary, the CLI would simply open communications to GDB.

VSCode Extension Debugging Feature

The VSCode extension would provide a graphical interface to the available debugging features. Users could set breakpoints, mark variables to watch, etc. A watch screen could be added to let users view variables in real-time without needing to break.

Serial device multiplexing

One issue I foresee is that if the debugger is going to communicate over USB, users could lose access to send data through the USB. Multiplexing the signals over the USB port would solve this. The user input and remote debugging could be multiplexed so that existing programs can use stdin/stdout/stderr as normal, and then the remote stub wouldn't see any data not intended for it.

Things to Consider

• Memory footprint of the remote stub
• More thoughtful implementation details for VSCode and the CLI
• What happens to devices when the program reaches a breakpoint? Should the robot stop when a breakpoint stops, or should devices continue doing what they were told?

[BennyBot]

I really like this idea. Especially the variable debugger. It reminds me of the RobotC debugging utility.
In terms of VSCode, that is a decent amount of work but seems realistic. If we can just use the existing pros terminal for communications to and from the brain, I don't think we will need to modify the CLI in any way. VSCode will just send the GDB commands and parse the results. However, the CLI is currently limited by not supporting wireless stdin through pros terminal, so we may want to increase that project's priority if/when we decide to do this.