Open gsmcmullin opened 7 years ago
The current implementation uses async mode. -exec-interrupt
is sent to interrupt the target. If the target does not stop, a SIGINT
is sent to GDB after a timeout. This works for interrupting blocking CLI commands, but is not documented. This strategy appears to work on Windows with remote targets, but on native targets GDB is killed by the signal. I presume this is because there is no way to send SIGINT
other than the CTRL_C_EVENT
through the console window, as described above.
Interruption of both native and remote targets is tested in the testsuite. Travis only runs the tests on Linux.
There are 4 different scenarios requiring different mechanisms for interrupting the target.
On POSIX systems:
SIGINT
directly to the childSIGINT
must be sent to GDBOn Windows systems:
DebugBreakProcess
with a handle to the child process.GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0)
can be used to sendSIGINT
to GDB, but this requires the sender to share a console window with GDB, and ignore the signal.POSIX signals are easily sent with Node's
process.kill(pid, signal)
. The problem remains of how to tell if the target is remote. These are options:SIGINT
to GDB, and then to reported PID if it hasn't halted after a timeout.How to even make Windows API calls from JS remains a mystery.
Windows API calls that may be useful to achieve this nonsense:
GDB async-mi mode may also be used to make MI run command asynchronous. Sending
-gdb-set async-mi on
puts GDB into async mode. After this the-exec-*
commands that resume execution run in the background, and further commands may be sent while the inferior is running. The-exec-interrupt
command may be sent to GDB to interrupt the target.CLI commands that resume the target will still block until the inferior stops. They may be explicitly run in the background by adding an ampersand to the command line.