Implement GDB/MI mode

[lextm]

I think it will be useful to implement the same GDB/MI mode to match netcoredbg because

• It would be convenient to allow debugging inside the terminal with MI commands
• Feature parity with netcoredbg can be an important feature itself
• Validate/improve the maturity of this new debugger by porting all netcoredbg test cases over

Some work has already been done so several pull requests will be sent over for review.

The first is #6 which modifies the launch behaviors to match netcoredbg.

[MattParkerDev]

Does vsdbg also provide GDB/MI support? I am just conscious of having as little code to maintain as possible.

porting all netcoredbg test cases over

I agree that this would be good to do, but I would like if when porting, we made the tests more readable like the existing ones I have implemented in SharpDbg.

[lextm]

Necessity

vsdbg only has the vscode mode.

vsdbg --help
Microsoft .NET Core Debugger (vsdbg)
Copyright (C) Microsoft Corporation.  All rights reserved.


Options:
--interpreter=vscode                  Standard input and output will contain
    Debug Adapter Protocol commands. This is currently the only supported
    interpreter mode and it is used for all Visual Studio products.

but vsdbg-ui has a command line interface --useManualInput,

$vsdbg-ui --help
VsDbg-UI: Debug adapter bridge for using vsdbg

Available command line arguments:
--server[=port_num] : Start the debug adapter listening for requests on the
    specified TCP/IP port instead of stdin/out. If port is not specified
    TCP 4711 will be used.
--pauseAdapterForDebugger: Pause the VsDbg-UI.exe process at startup until a
    debugger attaches.
--useLocalPipe: Use the pipe transport for local debugging.
--useManualInput: Use manually-entered input from the console. This bypasses
    the need for Content-Length, and reads lines straight from the console.
    In this mode, type "quit" or "exit" to close the program.
--engineLogging: Log communications to /Users/lextm/vsdbg-ui.log.
--consoleLogging: Log communications console.
All remaining arguments will be passed to vsdbg.

So, it would be either GDB/MI or a vsdbg-ui alone wrapper. Personally I still prefer to GDB/MI, and based on the current changes I made the total amount of code changes are manageable.

Test cases port

Porting test cases already revealed some gaps in SharpDbg (expression evaluation, etc.), so bit by bit I can investigate and resolve them.

The first priority I think is to ensure SharpDbg reaches feature parity with netcoredbg and more. Then we go back and see if the test cases can be improved to be more convenient to maintain. Overall, the MI based test cases look trivial to me.

[MattParkerDev]

Personally I still prefer to GDB/MI

Agree!

The first priority I think is to ensure SharpDbg reaches feature parity with netcoredbg and more. Then we go back and see if the test cases can be improved to be more convenient to maintain. Overall, the MI based test cases look trivial to me.

Okay, sounds good to me :)

[lextm]

@MattParkerDev Just sent a second pull request #9. The actual MI mode code is much larger, so I am doing cleanup right now,

• Extract common pieces into small pull requests Implement debugee launch #6 and Implement stop-at-entry #9
• Find a good way to reuse netcoredbg test files directly (they wrote those in C#, so why not)
• Find the right order to add test cases from netcoredbg, so that changes to SharpDbg can come in the order that eases code review

Hope this can be done well in the coming weeks, so you won't need to review a big chunk of changes all together.

Once feature parity is reached, we then go back and see how to rewrite the test files in the readable way you described.