[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?

[puremourning]

Another tricky part in vscode-go integration was to handle stdout/stderr from the debugged target

@hyangah does dlv dap not send runInTerminal request for the debugee? If so, how is stdin handled?

[hyangah]

@puremourning dlv dap won't include runInTerminal support based on my conversation with delve maintainers golang/vscode-go#1626 (currently, my failed attempt to convince them to make it a full debug adapter )

dlv dap always places the debugged program foreground. Is it possible to run dlv dap with the tty you want? (dlv has --tty flag but I don't know if it works with the dap command correctly and if it now works beyond non-unix system yet).

[puremourning]

so in order to debug processes that use standard input, vimspector would have to do seomthing like start dlv dap in a terminal with a tty, then communicate with it over a socket ? does it support that ? I don't know tbh if this is any different/regressive vs vscode-go.

The real reason I haven't done anything about this is that I don't use go often enough for it to affect me. There are a couple of things we would have to do:

• ensure that the dlv dap adapter provides feature-equivalence to vscode-cpptools
• ensure that existing users' configurations are not broken by changing the underlying adapter, or that it is trivial for users to migrate (e.g. just change the adapter)
• or, maintain both (sigh) for some unspecified amount of time
• update the tests
• add the new adapter and a way to automatically install dlv in the gadget dir, etc.

So like, it's a bunch of fiddly work that isn't a high priority for me personally. I'm happy to accept community contributions on this of course, but not breaking existing users is a must and avoiding supporting 2 ways to do go is a strong desirable, because I don't have the bandwidth to constantly ask "which adapter are you using" when someone inevitably says "go debugging no works" in Gitter or on GitHub issues/discussions.