delve/Documentation/api
Derek Parker 63a660820e docs: Move wiki docs into Documentation dir
Going forward, all documentation should be placed in the Documentation
directory in the root of the project. This switch allows maintainers to
approve updates to documentation before they are committed, as opposed
to the pre-existing wiki which anybody could modify.

Currently the Documentation directory includes docs on building, usage,
and minimal docs around the API. This is just the initial commit, and
documentation will continue to improve over time.

Some changes have been made (and will continue to be made) to `cmd/dlv` to
ensure we can auto-generate documentation for all commands from the
newly provided script `scripts/gen-usage-docs.go`, which can be invoked
via `go run scripts/gen-usage-docs.go`.

Additionally, version has been split into its own package. This was a
bit of housekeeping related to the changes made the `cmd/dlv`.
2016-02-19 10:47:46 -08:00
..
json-rpc docs: Move wiki docs into Documentation dir 2016-02-19 10:47:46 -08:00
README.md docs: Move wiki docs into Documentation dir 2016-02-19 10:47:46 -08:00

API Documentation

Delve exposes an API interface so that other programs, mostly IDEs and editors, can interact with Delve programmatically. The API is used by the terminal client, so will always stay up to date in lockstep regardless of new features.

Usage

In order to run Delve in "API mode", simply invoke with one of the standard commands, providing the --headless flag, like so:

$ dlv debug --headless --log --listen=127.0.0.1:8181

This will start the debugger in a non-interactive mode, listening on the specified address, and will enable logging. The last two flags are optional, of course.

Optionally, you may also specify the --accept-multiclient flag if you would like to connect multiple clients to the API.

You can connect the headless debugger from Delve itself using the connect subcommand:

$ dlv connect 127.0.0.1:8181

This can be useful for remote debugging.

API Interfaces

Delve has been architected in such a way as to allow multiple client/server implementations. All of the "business logic" as it were is abstracted away from the actual client/server implementations, allowing for easy implementation of new API interfaces.

Current API Interfaces