[Feature Request] custom support for issuing MI commands from another debug adapter

Type: General
This is a feature request, not a defect. Apologies in advance if this isn't the correct channel for submitting this sort of thing.

I would like to develop debug-related extensions on top of cppdbg and gdb, but the cppdbg debugger doesn't provide a way for other extensions to issue gdb MI commands and receive the output.

Here are a few concrete examples that affect me directly:

• ARM ecosystem debuggers generally use SVD files to describe how micro controller peripherals configuration registers are mapped in to the address space. e.g., M-class ARM processors are frequently used in very low power and very cost conscious applications. They also frequently have a large number of peripherals provided by the specific silicon vendor, and ARM has a standard file format called SVD that allows ARM micro controller vendors to describe how their peripheral configuration registers are mapped in to the address space of the processor. Development environments focused on this market frequently include an "SVD viewer" as part of their debug experience. The debugger uses the vendor-specific SVD file to read data from the target's memory, and decode that information and present in an easy to read format. It's MUCH easier than opening up the vendor's data sheet to find the right address and manually reading the memory at that address THEN decoding flags and bitfields.

• An optional / general purpose debug register view (REALLY useful for micro controller developers who are often compiling code targeting environments with bytes or maybe kilobytes of flash memory, are forced to build with optimizations turned on just to get their application to fit on the target device, and frequently have to debug in an assembly view to actually understand their apps on-device behavior).

There is no way (short of creating your own debug adaptor) to support this today, but it looks like this ought to be doable on top of cppdbg with a (hopefully small) enhancement. Specifically, I noticed that DebugSession provides a customRequest method. In turn, it raises a onDidReceiveDebugSessionCustomEvent on the debug adaptor with the custom information. If cppdbg handled onDidReceiveDebugSessionCustomEvent and documented a custom event arguments/structure that allowed other extensions to pass along GDB MI commands and receive the results, other extension developers code extend Visual Studio Code's debug capabilities without creating a whole debug adaptor.

In my specific case, I could get data from micro controller registers and memory and display them in a "debug" view pretty simply.

Describe the bug

• OS and Version: macOS, Windows, Linux
• VS Code Version: 1.29.1
• C/C++ Extension Version: 0.20.1
• Other extensions you installed (and if the issue persists after disabling them): none

To Reproduce
Attempt to write a new Visual Studio Code extension that adds a new "debug" view that requires information from the debug adaptor that isn't already provided via an Visual Studio Code extension API (e.g., list of registers and their values, value of data in memory).

Start with the DebugSession customRequest method and the onDidReceiveDebugSessionCustomEvent flow mentioned in the issue. Trace how cppdbg handles debug-session requests and events, then define and document the event arguments needed for extensions to submit GDB MI commands and receive results. Done means an extension can use this interface for register or memory views without creating a separate debug adapter.