Support mi2 protocol over "plain tcp" connection mode of operation

[oakad]

Presently, code-debug can either start a locally available gdb executable or open an ssh session to a remote host and spawn a gdb there talking mi2.

However, it will be really handy if code-debug could connect to a user specified host:port address in "plain tcp" mode, assuming that on the other side there's a gdb already running, ready to talk mi2. It appears (from a cursory glance at a code) that this can be easily achieved.

Why this is useful?

Primarily because of docker. Most docker containers have no sshd installed and invocation of commands in such containers is handled by all kinds of tools (docker compose, kubernetes, etc).

A developer, therefore, can easily invoke a command like nc -l -p <port> -c "gdb --interpreter=mi2" inside a container and point the code-debug extension at that port.

Why gdbserver is less useful in this scenario

1. Architecture mismatch. Often encountered examples include Linux containers on Docker for Windows, or, for example, Alpine Linux containers on Linux or Docker for Windows. Requires maintenance of all those cross-architecture gdb binaries.
2. The executable with all its libs may not be easily available outside the container, so additional tooling is required to get those out of container for gdb use, specialized gdbinit scripts, etc. gdb within the container will "just work".
3. Source code for "containerized" gdb can be properly arranged in a separate container built by the same CI system and "composed in" for debug purposes - the gdbserver approach with source code elsewhere may be very difficult to setup (same issues as p. 2 above).

[GitMensch]

I see why this is interesting - but for most of the cases this isn't necessary:

• you can use a single multiarch GDB (when using Windows for example the gdb-multiarch from MSYS2)
• you can use "extended-remote" to connect to the other side - in this case the executable and all libs are read via ssh when necessary
• because of the debug-adapter protocol and this extension using the vscode editor as a frontend you always need the source code where vscode can access it (its possible to use a network share, but that may be not that easy for a docker).

Note: I'm actually running gdbserver in a CentOS docker container this way and can debug from vscode from Windows (the source code is only on the vscode client, the executables only in the container, all using MSYS2's gdb-multiarch and extended-remote).

[oakad]

I'm not arguing that it was not possible to work something out under current implementation. My point was that a relatively minor enhancement makes life much, much easier, especially on cross-arch setups (especially considering the marked increase in AMD64/ARM interop needs).

[GitMensch]

I totally see the point of this. To benefit from this approach: How would you tackle the "source code needs still be on the container" (as gdb is run there) and within vscode (otherwise that won't work) issue?

[GitMensch]

A developer, therefore, can easily invoke a command like nc -l -p <port> -c "gdb --interpreter=mi2" inside a container and point the code-debug extension at that port.

man nc says

-p source_port Specifies the source port nc should use, subject to privilege restrictions and availability. It is an error to use this option in conjunction with the -l option.

So I guess that should be nc -l <port> -c "gdb --interpreter=mi2" instead. I've thought about ssh connections being most useful, but the point of missing sshd is definitely correct.

However, it will be really handy if code-debug could connect to a user specified host:port address in "plain tcp" mode, assuming that on the other side there's a gdb already running, ready to talk mi2. It appears (from a cursory glance at a code) that this can be easily achieved.

Can you please give that implementation a try? Would you still use ssh2 (possibly the "raw request variant") or do it different?