dlv dap: remote connect (aka remote attach)

[polinasok]

Background
The following debug configurations are offered to users in vscode-go.

• (1) Launch file/package/test: request='launch' mode='debug'/'test'/'exec' program=... (Local Debugging)
• (2) Attach to process: request='attach' mode='local' processId=... (Local Debugging)
• (3) Connect to server: request='attach' mode='remote' host=... port=... (Remote Debugging)

With traditional dlv, (1) and (2) configuration attributes are translated into cli arguments:

• (1) dlv debug/exec/test <program> --headless
• (2) dlv attach <pid> --headless

With dlv dap, the server command takes no args, but waits for the DAP client to tell it what to debug via

• (1) launch request arguments
• (2) attach request arguments

This difference is hidden under the hood and is irrelevant to the local debugging users - options (1) and (2) as the debug configuration is the only thing a user needs to provide.

In case of Remote Debugging, option (3), the user first starts the debug server on their own at host/port, locally or remotely, and then the client connects to it for the debug session as per the host/port in the debug configuration. Because the user deals with the server command directly, the differences in how program/pid are supplied come into light. In addition, remote debugging comes with the use case of connecting to the server with multiple client (tracked under #2323).

Remote Option 1 (Done)
If we follow the traditional DAP initialization sequence, the user would need to launch the server outside of the client, then use the client to start a debug session and tell the server what to launch/attach to (options (1) and (2) above). So essentially this means introducing new client-side configurations to express (3)+(1) and (3)+(2). This could look like:

• (3-1) Connect to server and launch: host=... port=... request='launch' mode='debug'/'test'/'exec' program=...
• (3-2) Connect to server and attach: host=... port=... request='attach' mode='local' processId=...

Host and port will be used to connect to dlv-dap. Request mode, etc will drive the launch/attach request sent to it just like they do in (1) and (2). Any additional configuration processing would need to be done on the client side. Dlv-dap can already support this bearing the considerations below.

Remote Option 2 (Done)
The above model is different from the current model that dlv users are used to where they specify pid or package/program on the command-line as part of launching the headless server. To make dlv-dap experience more familiar and behave like (3) above, we could add a couple more variants - dlv-dap-debug and dlv-dap-attach. These would accept the same command-line arguments as dlv-debug and dlv-attach and go straight to launching/attaching without the formal initialize and launch/attach requests. Then when a client finally connects to the server and does send a launch/attach request, it could be treated as a no-op or perhaps a sanity check that the server is indeed running the expected program. In other words, the server would do the following:

Launch/Attach Handler:
   if debugger.Debugger not null
      debug session is already in progress, so nothing to launch/attach
      (ignore launch/attach args unless we want to support verification)
   else 
      start debug session by creating debugger.Debugger to launch/attach based on args

This will also fit with a requirement that a remote server should be reusable between multiple debug sessions while being attached to the same process and having it run or be suspended even when without a client (see also #2323).

The supported attribute configuration could be the following

• host=... port=... request="attach" mode="remote" (we considered using "connect" or "external" to signal that this will be mostly a no-op request because we already attached/launched, but decided to go with the familiar legacy names after all)
  Note that if program or pid are also specified, they will be ignored because he server already stared debugging a program.
  We would need special handling for stopOnEntry (the server won't halt the program by default like in case of regular launch/attach).

Would this make more sense if DAP had a third kind of request ("connect"?) in place of launch/attach to signal the expectation that there is already a running process associated with the debugger that we are connecting to as-is? Maybe worth filing an DAP issue requesting this.

Other Considerations

1. We need to port whatever mechanisms vscode-go currently uses to map local and remote paths. Much of the logic currently exists on the TypeScript side and we need to see what should be moved into service/dap. This deserves its own issue and design discussion.
2. Many of the dlv command-line flags (e.g. for logging) that are provided with (1) and (2) modes above via the debug configuration (since dlv is launched on their behalf), will be specified by the user via the command-line directly. If the user also provides them in the debug configuration, do we ignore/disallow them or do we switch in-flight where possible and print errors otherwise?
3. We will need to make sure we follow the right protocols for termination, leaving the server running if it can accept multiple client connects (dlv dap: --accept-multiclient and --continue support #2323) and terminating it (or at least offering an option to) otherwise (see also debug: revisit remote attach disconnect/shutdown implementation golang/vscode-go#748)

What else?

@suzmue @hyangah

[polinasok]

@hyangah has expressed a concern that currently remote users are able to use a dlv-connect or a GoLand client alongside VS Code with the same headless remote server. But if the remote server can only serve DAP, that would not be possible even if we support --accept-multiclient (#2323) because these other clients use json-rpc, not DAP. Should there be a version of a dlv server that can accept clients of either kind?

[hyangah]

@polinasok thanks for the detailed documentation.

My concern is that the remote debugging workflow using DAP will be significantly different from the workflow well-established in the go community. Users have to define a different debug container. Depending on the editors and cli, they have to use different dlv commands. IMO, this is harmful for both VS Code users and the users of other editors and programs that depend on json-rpc.

Instead of introducing a new set of commands, what do you think about the following approaches?

1. make the dlv headless server speak both protocols (two separate ports?), or

2. make dlv dap optionally operate as a pure debug adapter server and be able to connect to the external headless dlv process. (note the emphasis on "option" because it's nice to have both dap and debug server in one binary in common cases)

I am personally in favor of 2) because it allows users to keep using their current dev/debug container definition, and affects users least. But I am afraid this additional capability will add complexity to dlv dap implementation.

--

Sometimes VS Code users rely on --accept-multiclient to connect to the headless debug server to utilize the power of dlv cli, e.g., inspecting deeply nested values, get more info not exposed through VS Code UI, etc. This is often a workaround to overcome the limitation of DAP or the current DAP implementation. Thus, without the ability to use different editors or cli/ui programs, I don't think --accept-multiclient functionality only for DAP is particularly useful.

[polinasok]

We have decided against exposing the remote option via the additional dlv-dap-debug/attach command (drafts here: #2652, #2648). Instead we will be integrating dlv request loop into the rpc server, so we can reuse its cli and machinery for multi-client support.

[aaomidi]

I might be reading this wrong, but is there a way to attach to a remote PID via go-delve right now?

E.g. some go binary is running in a container, and I want to attach to the PID of that from outside the container.

[aarzilli]

Closing, implemented by #2755. @aaomidi vscode-go has been able to do that for several years, this issue regards implementing it in delve's dap server. How this is used is explained in vscode-go's documentation.

[polinasok]

@aaomidi Here is the vscode-go debugging documentation:https://github.com/golang/vscode-go/blob/master/docs/debugging.md#remote-debugging