Debug Adapter Protocol

[dsvensson]

Not sure if it would be better to have something like this external to Delve, but a sibling project to the Language Server Protocol is starting to take form, in Debug Adapter Protocol. This is something that is rapidly gaining support in Emacs, but most servers are currently ripped out from Visual Studio Code plugins. There's currently a wrapper around delve for making it conform to DAP in Visual Studio Code. It's written in TypeScript, so it adds an extra universe of dependencies. It would be nice to cut a few layers for a more lean integration.

Emacs dap-mode:
https://github.com/emacs-lsp/dap-mode

VSCode Delve wrapper, also used by Emacs dap-mode:
https://github.com/Microsoft/vscode-go/tree/master/src/debugAdapter

Debug Adapter Protocol:
https://microsoft.github.io/debug-adapter-protocol/

[aarzilli]

If you want to implement this you can take a look at https://github.com/go-delve/delve/blob/master/service/rpc2/server.go. It would just be a matter of implementing the protocol and hooking it up to a command line command in https://github.com/go-delve/delve/blob/master/cmd/dlv/cmds/commands.go

[dsvensson]

Yep, started looking in that direction. Would you consider this a separate project or an addition to delve, like cmd/dap or something?

[aarzilli]

I think it would be fine to have a subcommand, like dlv debugger-adapter-server.

[eliben]

@aarzilli a potential issue with a new command like dlv debugger-adapter-server is that currently delve can accept several commands in "server mode", like dlv exec and dlv debug with --headless (and also derivative commands like attach, and probably more). It'd be good to be able to do all these in DAP mode too.

It almost seems like DAP could be a new "API version", like: dlv exec --headless --api-version dap, but API version is an int flag. So a few options:

1. We could change the flag type to be string and accept "dap" in addition to "1" and "2"
2. We could use some numeric API version for DAP, e.g. version 3 is DAP, or version 30, etc.
3. We could just use a different flag, like --dap. This flag would be mutually exclusive with --api-version and would only work in --headless mode.

What do you think?

[aarzilli]

I was proposing the debugger-adapter-server verb because the DAP protocol has its own way to start the debugger if we are better off skipping that part of the protocol (and it can be skipped) then --api-version=dap is fine too. I don't know how language extensions and VScode interact to start a debugger.

I don't think there's any problem with changing the type of api-version to be a string.

[alur]

@dsvensson are you planning to work on this? If not I'd be happy to take it on.

[aarzilli]

I believe work on this is being currently done by google employees.

[dsvensson]

@alur Not relevant to me any longer. But seems to be in good hands. ^^^

[eliben]

As @aarzilli points out, it's being worked on. We began by implementing a standalone module for handling the DAP protocol at https://github.com/google/go-dap (this repo is open now). We're currently working on a prototype of integrating this into Delve, which we'll likely send out as a PR that can be discussed with the Delve maintainers. Once the general direction is approved, we'll work on getting the rest of the implementation working.

[derekparker]

We have merged support for a DAP server. Work is still ongoing, but I think the spirit of this issue is resolved.