Documentation
¶
Overview ¶
Package dap implements VSCode's Debug Adaptor Protocol (DAP). This allows delve to communicate with frontends using DAP without a separate adaptor. The frontend will run the debugger (which now doubles as an adaptor) in server mode listening on a port and communicating over TCP. This is work in progress, so for now Delve in dap mode only supports synchronous request-response communication, blocking while processing each request. For DAP details see https://microsoft.github.io/debug-adapter-protocol.
Index ¶
Constants ¶
const ( UnsupportedCommand int = 9999 InternalError int = 8888 NotYetImplemented int = 7777 // Where applicable and for consistency only, // values below are inspired the original vscode-go debug adaptor. FailedToLaunch = 3000 FailedToAttach = 3001 FailedToInitialize = 3002 UnableToSetBreakpoints = 2002 UnableToDisplayThreads = 2003 UnableToProduceStackTrace = 2004 UnableToListLocals = 2005 UnableToListArgs = 2006 UnableToListGlobals = 2007 UnableToLookupVariable = 2008 UnableToEvaluateExpression = 2009 UnableToHalt = 2010 UnableToGetExceptionInfo = 2011 UnableToSetVariable = 2012 // Add more codes as we support more requests DebuggeeIsRunning = 4000 DisconnectError = 5000 )
Unique identifiers for messages returned for errors from requests. These values are not mandated by DAP (other than the uniqueness requirement), so each implementation is free to choose their own.
const BetterBadAccessError = `` /* 211-byte string literal not displayed */
Variables ¶
var DefaultLoadConfig = proc.LoadConfig{ FollowPointers: true, MaxVariableRecurse: 1, MaxStringLen: 512, MaxArrayValues: 64, MaxStructFields: -1, }
DefaultLoadConfig controls how variables are loaded from the target's memory. These limits are conservative to minimize performace overhead for bulk loading. With dlv-dap, users do not have a way to adjust these. Instead we are focusing in interacive loading with nested reloads, array/map paging and context-specific string limits.
Functions ¶
This section is empty.
Types ¶
type Server ¶
type Server struct {
// contains filtered or unexported fields
}
Server implements a DAP server that can accept a single client for a single debug session (for now). It does not yet support restarting. That means that in addition to explicit shutdown requests, program termination and failed or closed client connection would also result in stopping this single-use server.
The DAP server operates via the following goroutines:
(1) Main goroutine where the server is created via NewServer(), started via Run() and stopped via Stop(). Once the server is started, this goroutine blocks until it receives a stop-server signal that can come from an OS interrupt (such as Ctrl-C) or config.DisconnectChan (passed to NewServer()) as a result of client connection failure or closure or a DAP disconnect request.
(2) Run goroutine started from Run() that serves as both a listener and a client goroutine. It accepts a client connection, reads, decodes and dispatches each request from the client. For synchronous requests, it issues commands to the underlying debugger and sends back events and responses. These requests block while the debuggee is running, so, where applicable, the handlers need to check if debugging state is running, so there is a need for a halt request or a dummy/error response to avoid blocking.
This is the only goroutine that sends a stop-server signal via config.DisconnecChan when encountering a client connection error or responding to a (synchronous) DAP disconnect request. Once stop is triggered, the goroutine exits.
TODO(polina): add another layer of per-client goroutines to support multiple clients
(3) Per-request goroutine is started for each asynchronous request that resumes execution. We check if target is running already, so there should be no more than one pending asynchronous request at a time. This goroutine issues commands to the underlying debugger and sends back events and responses. It takes a setup-done channel as an argument and temporarily blocks the request loop until setup for asynchronous execution is complete and targe is running. Once done, it unblocks processing of parallel requests unblocks (e.g. disconnecting while the program is running).
These per-request goroutines never send a stop-server signal. They block on running debugger commands that are interrupted when halt is issued while stopping. At that point these goroutines wrap-up and exit.
func NewServer ¶
NewServer creates a new DAP Server. It takes an opened Listener via config and assumes its ownership. config.DisconnectChan has to be set; it will be closed by the server when the client fails to connect, disconnects or requests shutdown. Once config.DisconnectChan is closed, Server.Stop() must be called to shutdown this single-user server.
func (*Server) Run ¶
func (s *Server) Run()
Run launches a new goroutine where it accepts a client connection and starts processing requests from it. Use Stop() to close connection. The server does not support multiple clients, serially or in parallel. The server should be restarted for every new debug session. The debugger won't be started until launch/attach request is received. TODO(polina): allow new client connections for new debug sessions, so the editor needs to launch delve only once?
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package daptest provides a sample client with utilities for DAP mode testing.
|
Package daptest provides a sample client with utilities for DAP mode testing. |
|
gen
command
Binary gen generates service/dap/daptest/responses.go.
|
Binary gen generates service/dap/daptest/responses.go. |