[Feature Request]: Switch to using Delve DAP support?

[puremourning]

go-delve/delve#1515

It looks like they merged DAP support in Delve directly. This might be better than relying on the (mostly unnecessary) vscode-go bloat which is likely only tested with vscode.

Switching to debugpy was a great choice and much better than vscode-python.

[puremourning]

Server is still way too immature to switch to this.

For the record the following works with the example in support/test/go/hello_world:

{
  "adapters": {
    "dlv-dap": {
      "variables": {
        "port": "${unusedLocalPort}"
      },
      "command": [
        "$HOME/go/bin/dlv",
        "dap",
        "--listen",
        "127.0.0.1:${port}"
      ],
      "port": "${port}"
    },
    "run-dap": {
      "adapter": "dlv-dap",
      "default": true,
      "configuration": {
        "request": "launch",
        "env": { "GO111MODULE": "off" },

        "mode": "debug", // debug|test...
        "program": "${workspaceRoot}/hello-world.go",

        // "args": [],
        // "buildFlags": ...
        // "stackTraceDepth": ...,
        // "showGlobalVariables": true,
      }
    }
}

Reverse engineering is the only way to determine th launch arguments: https://github.com/go-delve/delve/blob/master/service/dap/server.go#L434

[myitcv]

FWIW I'm having good success thus far with dlv-dap:

Delve Debugger
Version: 1.6.1
Build: $Id: 114218c22f3791287c4bc2f4ff35a846a1416ee9 $

I'll be sure to report any issues I do come across.

[puremourning]

As the closest thing I know to a go expert, I shall trust your judgement!

if it works well then I’m keen to deprecate the typescript vscode plugin none sense and switch to it.

[myitcv]

cc @hyangah @aarzilli

[mrbeardad]

emm, sorry, I get the error when use dlv-dap

Request for initialize aborted: Timeout

threr is my .vimspector.json

{
    "adapters": {
        "dlv-dap": {
            "variables": {
                "port": "${unusedLocalPort}"
            },
            "command": [
                "$HOME/go/bin/dlv",
                "dap",
                "--listen",
                "127.0.0.1:${port}"
            ],
            "port": "${port}"
        }
    },
    "configurations": {
        "run": {
            "adapter": "vscode-go",
            "configuration": {
                "request": "launch",
                "mode": "debug",
                "program": "${file}",
                "dlvToolPath": "/bin/dlv",
                "trace": true,
                "env": { "GO111MODULE": "off" }
            }
        },
        "run-dap": {
            "adapter": "dlv-dap",
            "configuration": {
                "request": "launch",
                "mode": "debug",
                "program": "${file}",
                "dlvToolPath": "/bin/dlv",
                "trace": true,
                "env": { "GO111MODULE": "off" }
            }
        },
        "run-exec": {
            // NOTE: To use this you _must_ disable optimistaion:
            // go build -o hello_world -gcflags="all=-N -l"
            "adapter": "vscode-go",
            "configuration": {
                "request": "launch",
                "mode": "exec",
                "program": "${file}.exe",
                "dlvToolPath": "/bin/dlv",
                "trace": true,
                "env": { "GO111MODULE": "off" }
            }
        }
    }
}

[puremourning]

Delve DAP doesn't support remote debugging at present so we can't switch to it.

[hyangah]

@puremourning Great timing since we are still working on polishing remote debugging features. Can you please clarify what you meant by 'remote' debugging for vimspector users?

If users are willing to run dlv dap --listen=host:port command instead of dlv debug --headless or dlv test --headless commands like before, debugging a target running on a remote host where the dlv dap server is running is possible. We are planning to make dlv debug --headless and dlv test --headless understand DAP too so users don't need to change their containers or scripts for remote debugging.

Launching/attaching to a target on a host remote from the debug adapter is not supported and won't be supported.

[puremourning]

If users are willing to run dlv dap --listen=host:port command instead of dlv debug --headless or dlv test --headless commands like before, debugging a target running on a remote host where the dlv dap server is running is possible.

oh really. In that case it’s fine IMO. Users have to do that sort of thing for other adapters anyway and vimspector can even run it for you.

I was really just parroting what I just read on the vscode-dap docs.

So I guess we can switch to it in the same way we switched from vscode-python to debugpy ie deprecate vscode-go support and remove after 1 year.

Anything else I should need to know ? Any other caveats or custom DAP stuff?

[hyangah]

Thanks @puremourning AFAIK, I don't see anything else - maybe update the documentation. :-)

One tricky part we found today is: dlv dap is usable only with recent versions of Delve. (1.6.1+) and Delve officially supports 3 latest Go versions. So, if users want to debug a program with an old Go version, users will need to either 1) fall back to the legacy adapter, or 2) start Delve with --check-go-version=false taking a risk.

Another tricky part in vscode-go integration was to handle stdout/stderr from the debugged target. The current dlv dap implementation does not send the debugee's stdout/stderr as OutputEvents. They are sent directly to stdout/stderr of the dlv dap process. VSCode Go worked around it by implementing an inline adapter in the extension that reads stdout/stderr and generates OutputEvents. But based on the users' success story, that's not an issue for vimspector users.

[leoluz]

I'd like to give vimspector + dlv dap a try.
Is there any piece of guide drafted somewhere already?

[puremourning]

@leoluz you mean like this ? #186 (comment)

[leoluz]

@puremourning Ok. I'll give that a try. I just wanted to follow the latest guide you have regarding that and that comment is from March so I wasn't sure. tks

[hyangah]

@puremourning The documentation for launch/attach args is in https://pkg.go.dev/github.com/go-delve/delve@master/service/dap#pkg-types

Is there anything that you want us to clarify or fix before using dlv dap as the default Go debug adapter?