Support for multi-adapter launch

[eltonwells]

Currently it seems the only way to handle mixed-mode debugging scenarios is to launch with one debugger, hit a breakpoint, and then attach with another debugger. A few examples online:

• Mixed debugging with C++ and Python (example 1)
• Mixed debugging with C++ and Python (example 2)
• Mixed debugging with C++ and C# (example 1)
• Mixed debugging with C++ and C# (example 2)

In Visual Studio we can do a multi-engine launch via IVsDebugger::LaunchDebugTargets where VsDebugTargetInfo::pClsidList can contain CLSIDs for multiple debug engines. In this scenario, the first debug engine is responsible for launching and then the other(s) attach. For an example of this in the Python PTVS tools, see DebugLaunchHelper.cs.

Can something analogous be supported in VS Code? Apart from the launch.json changes, I think main message updates would be requests for launch suspended (or a new field in the Launch request).

[connor4312]

In VS Code we use compound launch configurations for this, for example this is a configuration we use to launch VS code and attach to three other associated programs: https://github.com/microsoft/vscode/blob/f63ceed2b004502fffcdf40643aa4a9761a38abe/.vscode/launch.json#L434-L447

The key thing that the debugger doing attaching needs to support is the ability to poll in the event that its target is not ready when the debug session is initiated.

Another approach we've taken is to have the debug extension (or a helper extension) trigger a session based on some event, e.g. with the serverReadyAction.

[eltonwells]

@connor4312 Thanks for the information on compound launch configurations. One question I have about this approach:

• Consider for example C++ and Python scenario, configured as a compound launch instead.
• Breakpoint is set in C++ code, expected to be hit very early in program execution.
• Python debugger launches, C++ debugger attaches.
• What guarantees the program doesn't run past the C++ breakpoint before the C++ debugger attaches?

Also regarding the option to trigger a session based on an event, this would be triggering a session via vscode.debug.startDebugging?

[connor4312]

What guarantees the program doesn't run past the C++ breakpoint before the C++ debugger attaches?

Something in the debugger would have to do that. In JS debugging, for example, you can launch a program with --inspect-brk which causes it to pause before the first line of code until a debugger attaches.

Also regarding the option to trigger a session based on an event, this would be triggering a session via vscode.debug.startDebugging?

Yep.

[eltonwells]

@connor4312 One other question, in the compound launch scenario how much coordination is there between the debug adapters in the debug session? For example, if one DA stops do the other(s) get a pause request? Is the behavior consistent here between a compound launch and when an extension triggers additional sessions (eg, serverReadyAction, vscode.debug.startDebugging, etc.)?

[connor4312]

VS Code does not do very much to coordinate them. In compound launches, there's a stopAll option to configure whether the user ending one session should terminate the others, but that's all.

[weinand]

Yes, as already pointed out by @connor4312, the current approach to mixed-mode (and multi process) debugging scenarios is to handle this outside of DAP.

Reasons being:

• scenarios are too diverse and we could not come up with DAP concepts to cover all cases,
• VS Code features like "auto-attach" (e.g. "auto-attach" extension and js-debug), "multi-process debugging" (via compounds or js-debug), "mixed-mode debugging" (via compounds and "serverReadyAction" extension) have shown that they can be easily implemented on top of the existing DAP (either in VS Code or in extensions). Since there is no need for debug extension to support new DAP requests, all existing debug extensions could automatically participate in these features.

If there is anything that is too difficult to do outside of DAP, we can easily extend DAP. But for the sake of simplicity, we need good reasons to do so...

[int19h]

Mixed-mode is not as easy as just having one debugger launch, and the rest attach: the debug adapters need to be aware of each other and co-operate, otherwise one of them can block the others. E.g. in the C++/Python case, if the native debugger pauses in native code, the paused thread can no longer evaluate Python code - which the Python debugger needs to produce stack traces etc. There's also no way to get e.g. a mixed stack trace in this model.

VS eventually came up with a whole new API specifically to allow debug engines to co-operate on stack traces and stepping, and that's the one powering mixed Native/Python experience in VS. So for that to happen in VSCode, it'll need something similar first.