-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Target interruption #2
Comments
The current implementation uses async mode. 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.
The text was updated successfully, but these errors were encountered: