Add "send signal" button to debug toolbar

[jimbobmcgee]

I would like for there to be standardised support for simulating (for example) pressing CTRLC to programs running in the debugger. I appreciate that...

• CTRLC is probably bound to a clipboard copy action
• the implementation of CTRLC is OS-specifiic (SIGINT vs GenerateConsoleCtrlEvent)
• integration with the Debug Console is probably language-specific (I am assuming)

I don't know how feasible this is (and maybe overthinking it) but, if it is feasible, a potentially-reasonable approach might be to offer a split-button in the Debug toolbar (i.e. the one that comes up when debugging, with the Play, Pause, Step, Stop, etc. buttons), that provides a drop-down of valid signals (for the OS); and sends whatever message/event trigger exists to the debugger, so that the language provider can do the last-hop (e.g. sending POSIX SIGINT, or calling Win32 GenerateConsoleCtrlEvent).

I do have a short-term workaround -- at least, one that works when I am writing Go code on my Linux machine (for example): I can run pkill -INT __debug_bin in the Terminal view (since debugging go programs are typically compiled to a __debug_bin for running). However, I can't do the same when I am on my Windows machine (e.g. taskkill /im __debug_bin) because it requires taskkill /f, which is a "harder" kill than CTRLC seems to be. I also don't expect all languages use __debug_bin as their debug build target, so there would need to be a way for those providers to supply the right image name (or PID, dwProcessGroupId, etc.).

Standardising a button in the UI might eventually allow for the best all-round user experience, and would at least offer a jump-off point for implementers (rather than them all coming up with their own approaches).

[weinand]

VS Code debuggers already support to send CTRL to debuggees.

If a debug extension has opted into the Terminate request, VS Code will send a Terminate to the debug adapter if the "Stop" is executed. Debug extensions are expected to implement the Terminate request by sending a SIGINT to the debuggee which gets a chance to clean up and terminate properly. If the debuggee doesn't react on SIGINT by terminate itself, executing "Stop" another time will terminate the debuggee forcefully.

VS Code's builtin JavaScript debugger supports this behavior (besides others).

If the Go debugger does not support this, please file a feature request against it.

[jimbobmcgee]

@weinand - thanks for looking, but I wonder if this has been closed a little too quickly. This wasn't a bug or problem with a cause, but a feature request I wanted for VSCode (I did use the Feature Request template, but it might not be clear enough).

From what you are saying, I now understand that the Stop button triggers a Terminate request, and that the debug implementers can subscribe to receive this request, so as to perform cleanup before ending the debug session. That they are cleaning up their debugger, without necessarily forwarding the SIGINT onto my program, may indeed be construed as a bug/problem in their implementation.

However, what I am asking is for a standardised way to inform the debug implementation of arbitrary, platform-independent signals (including SIGINT), e.g. a Signal request, which the debug implementers can also opt into, with the intention of simulating the receipt of these signals during a debug session without stopping that debug session. Sending CTRLC is only an example (albeit a tangible one), there are many other events that might be of interest to a program, that are also interesting to the debugger implementation, and this would allow us to differentiate between the two.

A use case is for those of us who want to debug our own programs which themselves handle these signals. Using my own experiences with the Go provider as an example, pressing Stop terminates the debug session. Any breakpoints placed in my Go code during or after the signal, ok := <- signals line in my code are never reached, because the Go provider has torn down the debug session already. I appreciate that this specific example might be an issue with the Go provider's current implementation of the Terminate handler, and realise that doing the right thing with regards to a new Signal event is also the responsibility of the Go language implementer.

(I could also see use case for sending Windows messages, such as WM_SETTINGCHANGE, without having to actually alter one's system settings, for example.)

My feature request is to standardise an interface for the discovery, emission and acceptance of those signals (both API and UI), so that the concept is well-defined within VSCode, and one can go to the language providers and ask them to implement the Signal event for their debugger.

(Unless, of course, it is trivial for a language provider to add their own button to the debug toolbar, and handle it by sending SIGINT without terminating the debugger...?)

[weinand]

It seems I was not successful in bringing the idea of the Terminate request across:

The sole purpose of the Terminate request is to send whatever is necessary to the debuggee (the program being debugged) so that it can do what it needs to do. This might include to shut down itself (the debuggee) gracefully. That's the reason why the request is called "terminate". But the debuggee could do something else (and not shut down itself).

The purpose of the Terminate request is not to cleanup the debugger or terminate the debug session. The debug session is only terminated if the debuggee decides to "exit" (for whatever reason, including receipt of the Terminate request).

So Terminate is basically an abstraction on top of the "SIGINT" signal (or the corresponding Windows equivalent). We have to use an abstraction because "signals" and "processes" are not something the VS Code debugger knows about. So VS Code cannot provide a UI to send arbitrary signals to processes because it knows neither.

If you need a mechanism to send arbitrary signals to Go processes, then the Go extension can provide the UI for it. On the level of Go you know that there are processes and that there is a mechanism to send signals.