@@ -150,6 +150,82 @@ Here's launch.json for a specific program to run when debugging the debugging ad
...
@@ -150,6 +150,82 @@ Here's launch.json for a specific program to run when debugging the debugging ad
}
}
```
```
## Handling COBOL "ACCEPT" instructions needs to be improved.
Version 4.2.3 has a "halfway" implementation of coping with COBOL "ACCEPT" instructions. When debugging with command-line GDB, by default both GDB and the launched inferior program accept input and generate output on the same TTY instance. GDB can be instructed to direct the inferior's input/output to a different TTY with the "-tty=" command line parameter. But having them both use the same instance works perfectly well, although it requires sorting out the GDB output from the inferior's output.
But that modality doesn't work well with Visual Studio Code, which itself is multi-threaded. It leads to race conditions, where the COBOL program is trying to ACCEPT keystrokes from STDIN while at the same time VSC is sending asynchronous commands via STDIN and expecting responses on STDOUT.
Version 4.2.3 manages to work around this. First, it keeps track of whether the program is *running or *stopped. When *running, the debugging adapter blocks VSC from sending commands to GDB. It detects inputs that are supposed to be to the inferior, and it lets them through in raw form.
When I noted that sometimes the first characters of inputs to the inferior were somehow being lost, I added a 100-millisecond "freeze" on Visual Studio Code processing after sending data to the inferior. That seems to have eliminated the truncation problem. But I don't know for sure.
I investigated how Microsoft handles this in their C/C++ debugging extension. They somehow assign the inferior TTY (using the GDB --tty= switch) to the VSC "Integrated Terminal" pane; I have been unable to figure out how the determine the /dev/pts/x determination for that pain. For communication to GDB, they set up a couple of pipes: one for input, the other for output.
To sum up, when they invoke GDB, the command being issued looks like this:
Somehow or other the critical `tty=$DbgTerm` variable is being set with the
DbgTerm=`tty`
command. How that is run in the proper Visual Studio Code window pane, I do not know. Nor do I see how the Intergrated Terminal is set to run without a shell program.
The difficulties and time involved in exploring these questions are why I haven't yet implemented them.
-- Bob Dubner, 2021-03-19
Here is the launch.json I used for debugging a C/C++ program. Note the logging options that cause a certain amount of feedback in the DEBUG OUTPUT window.
```
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387