v5gdb can interrupt a call to an SDK function, then call that function (or related functions) again from the debug monitor.
For example, the user might press Ctrl-C in the middle of an incomplete serial write (vexSerialWriteBuffer). Then, from the debug monitor, v5gdb would almost certainly write its own serial data in the middle of the user's data.
This could pretty easily lead to garbled serial output or cause corruption of VEXos state.
Suggested fix
There are a couple of ways to go about fixing this.
- We could find a way to ignore all breakpoints triggered from VEXos code.
- We could introduce a "breakpoint critical section" that disables breakpoints for a period of code, then patch certain VEXos functions to use it (probably vexSerialWriteBuffer, maybe vexTasksRun).
v5gdb can interrupt a call to an SDK function, then call that function (or related functions) again from the debug monitor.
For example, the user might press Ctrl-C in the middle of an incomplete serial write (
vexSerialWriteBuffer). Then, from the debug monitor, v5gdb would almost certainly write its own serial data in the middle of the user's data.This could pretty easily lead to garbled serial output or cause corruption of VEXos state.
Suggested fix
There are a couple of ways to go about fixing this.