Adds field to breakpoint struct to track how a breakpoint was
originally set, moves the logic for disabling and enabling a breakpoint
to proc.
This will allow creating suspended breakpoints that are automatically
enabled when a plugin is loaded. When follow exec mode is implemented
it will also be possible to automatically enable breakpoints (whether
or not they were suspended) on new child processes, as they are
spawned.
It also improves breakpoint restore after a restart, before this after
a restart breakpoints would be re-enabled using their file:line
position, for breakpoints set using a function name or a location
expression this could be the wrong location after a recompile.
Updates #1653
Updates #2551
Remove leftover references to $GOPATH in documentation, change script
that generates markdown documentation to look for substrings that start
with "Documentation/" instead.
For commands that could produce large amounts of output switch to a
pager command ($DELVE_PAGER, $PAGER or more) after a certain amount of
output is produced.
Fixes#919
* terminal/command: 'goroutines' command add new flags '-exec command'
Support run command on every goroutine.
Fixes#3043
* terminal/command: 'goroutines' command add new flags '-exec command'
Support run command on every goroutine.
Fixes#3043
* terminal/command: add -per-g-hitcount option to condition command
Support use per goroutine hitcount as hintcond operand.
Fixes#3050
Co-authored-by: roketyyang <roketyyang@tencent.com>
1. return an error when SetUProbe fails, while creating ebpf tracepoints
2. if no tracepoint can be set for 'dlv trace' exit early
3. never leave the traced program running
4. fix typo in description of --ebpf flag
Fixes#3006
Often in the CLI documentation we were to inputs as linespec
when in reality we mean locspec which is a
location specifier, not necessarily a
line specifier.
This commit improves the handling of hardcoded breakpoints in Delve.
A hardcoded breakpoint is a breakpoint instruction hardcoded in the
text of the program, for example through runtime.Breakpoint.
1. hardcoded breakpoints are now indicated by setting the breakpoint
field on any thread stopped by a hardcoded breakpoint
2. if multiple hardcoded breakpoints are hit during a single stop all
will be notified to the user.
3. a debugger breakpoint with an unmet condition can't hide a hardcoded
breakpoint anymore.
* service: Implement BuildID
Parse the BuildID of executables and provides it over the RPC
service.
Signed-off-by: Morten Linderud <morten@linderud.pw>
* command: Support debuinfod for file listing
Signed-off-by: Morten Linderud <morten@linderud.pw>
* debuginfod: create debuginfod package for common code
We remove the duplicated code and provide our a new debuginfod package.
Signed-off-by: Morten Linderud <morten@linderud.pw>
* starlark: Workaround for 'build_i_d'
Signed-off-by: Morten Linderud <morten@linderud.pw>
* command: Ensure we only overwrite path when one has been found
Signed-off-by: Morten Linderud <morten@linderud.pw>
* bininfo: Inline parseBuildID
Signed-off-by: Morten Linderud <morten@linderud.pw>
Adds a transcript command that appends all command output to a file.
This command is equivalent to gdb's 'set logging'.
As part of this refactor the pkg/terminal commands to always write to a
io.Writer instead of using os.Stdout directly (through
fmt.Printf/fmt.Println).
Fixes#2237
* Documentation: add DAP API page
* Respond to review feedback
* Clarify about Ctrl-C
* Add hidden TODO for more things to document
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
This could probably be more user-friendly, in that you can't give a name
to such a breakpoint. To add support for names, we would need to try
a single arg first as a location, and if that fails try it as a name for
current line. That seems somewht dubious, so I didn't try.
There are persistent issues with watchpoints on Windows, it is not
clear whether it's a problem with the VM running the tests or if there
is a real bug in our implementation of hardware breakpoints on Windows.
Until the cause can be determined watchpoints on Windows will be
disabled.
Updates #2768
This adds a new `--client-addr=host:port` flag to `dlv dap`.
If it is supplied, the dap process will dial into the tcp port where
a DAP client is waiting, and work with only the DAP client.
The DAP client is supposed to start the normal DAP message
exchange starting with the 'initialize' request after the dlv dap
process dials in and the connection is set up.
VS Code Go extension plans to use this mode for
* reliably detecting `dlv dap` readiness. Currently it depends on
watching the log stream. After this PR, it can listen on a network port.
* running `dlv dap` from any terminal (part of RunInTerminal workflow
implementation).
Adds watchpoint support to gdbserver backend for rr debugger and
debugserver on macOS/amd64 and macOS/arm64.
Also changes stack watchpoints to support reverse execution.
* service/dap: add test verifying handling of relative program path
* Add exec test, log build dir and document in --help
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* terminal,service: add way to see internal breakpoints
Now that Delve has internal breakpoints that survive for long periods
of time it will be useful to have an option to display them.
* proc,terminal,service: support stack watchpoints
Adds support for watchpoints on stack allocated variables.
When a stack variable is watched, in addition to the normal watchpoint
some support breakpoints are created:
- one breakpoint inside runtime.copystack, used to adjust the address
of the watchpoint when the stack is resized
- one or more breakpoints used to detect when the stack variable goes
out of scope, those are similar to the breakpoints set by StepOut.
Implements #279
Before this change when you typed `help` at the Delve prompt you would
only see the following:
```
examinemem (alias: x) Examine memory:
```
Now with this patch the output is more descriptive:
```
examinemem (alias: x) Examine raw memory at the given address.
```
* cmd/dlv: dlv version --verbose
That prints out runtime/debug.BuildInfo read from the dlv binary.
Users can retrieve the same info using `go version -m <path_to_dlv>`
but I think it is convenient to have.
If dlv was built from cloned delve repo:
```
$ ./dlv version -v
Delve Debugger
Version: 1.7.0
Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $
Build Details: go1.16.5
mod github.com/go-delve/delve (devel)
dep github.com/cosiner/argv v0.1.0 h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg=
...
```
If dlv was built with `go install github.com/go-delve/delve@latest`
with go1.16+, or
`GO111MODULE=on go get github.com/go-delve/delve@latest`
from a clean main module:
```
$ ./dlv version -v
Delve Debugger
Version: 1.7.0
Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $
Build Details: go1.16.5
mod github.com/go-delve/delve v1.7.0
dep github.com/cosiner/argv v0.1.0 h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg=
...
```
* remove an accidentally added bogus test
This removes indirect dependencies from go.mod, and
includes the fix for the missing -help flag info.
The latest cobra release is v1.2.1. Given that there were
minor security-related dependency cleanup during v1.2 release,
I was tempted to pick up the latest version, but that caused
dependency updates in golang.org/x/sys and golang.org/x/tools
which may be too recent (golang.org/x/* follow the go's release
support policy, so recent versions may not be compatible with
go versions beyond go's official version support policy).
Verified that dlv still builds with go1.12.x.
(go1.12 is the oldest version of go that can build the latest delve already).
$ go get -d github.com/spf13/cobra@v1.1.3
$ go mod tidy
$ go mod vendor
$ go run _scripts/gen-usage-docs.go
* terminal: improve 'on' command
Adds the ability to edit the list of commands executed after stopping
on a breakpoint, as well as converting a breakpoint into a tracepoint
and vice versa.
Prior to this it was possible to add commands to a breakpoint but
removing commands or changing a breakpoint into a tracepoint, or vice
versa, could only be done by removing and recreating the breakpoint.
This PR aims to add support for rr replay and core actions from the DAP layer. This basically encloses the following:
New launch modes: replay and core
The following modes are added:
replay: Replays an rr trace, allowing backwards flows (reverse continue and stepback). Requires a traceDirPath property on launch.json pointing to a valid rr trace directory.
Equivalent to dlv replay <tracedir> command.
core: Replays a core dump file, showing its callstack and the file matching the callsite. Requires a coreFilePath property on launch.json pointing to a valid coredump file.
Equivalent to dlv core <exe> <corefile> command.
Dependencies
To achieve this the following additional changes were made:
Implement the onStepBackRequest and onReverseContinueRequest methods on service/dap
Adapt onLaunchRequest with the requried validations and logic for these new modes
Use CapabilitiesEvent responses to enable the StepBack controls on the supported scenarios (see dicussion here)
Add the corresponding launch.json support on vs code:
Support for replay and core modes golang/vscode-go#1268
ConvertEvalScope() attempts to find the scope for the specified
goroutine id and frame index. If the goroutine that is found is nil,
then it falls back to the threads stack trace to find the scope.
This fix makes sure that the frame id is taken into account for
thread strack traces as well.
Adds filtering and grouping to the goroutines command.
The current implementation of the goroutines command is modeled after
the threads command of gdb. It works well for programs that have up to
a couple dozen goroutines but becomes unusable quickly after that.
This commit adds the ability to filter and group goroutines by several
different properties, allowing a better debugging experience on
programs that have hundreds or thousands of goroutines.
