Use of `replace` in go.mod breaks delve installation using
`go install`. (see https://github.com/golang/go/issues/40276)
Workaround this limitation by explicitly require the fork
github.com/go-delve/liner.
go-delve/liner@v1.2.2-1 already has go.mod module name fixed
to be github.com/go-delve/liner.
Fixesgo-delve/delve#2904
* pkg/terminal: support ctrlz for shell job control
This required forking peterh/liner under the go-delve org and using that
instead since upstream is not open to supporting this feature.
Fixes#2157
* Update liner
* Update liner but correctly this time
* upgrade golang.org/x/tools to 0.1.9
* 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
It's possible that an inlined function call also contains an inlined
sunroutine. In this case we should also parse the children of
inlined calls to ensure we don't lose this information.
This is a partial revert of PR #2660.
Some users develop in environments where execution of binaries
in temp directory is prohibited or undesirable. Moreover, the
current implementation creates binaries with random names
and that made it more difficult to set up firewall exclusion
rules. Revert it and always use the default debug output name.
(The debug binary will be created in the delve's working directory
and an editor does not have any promise on working directory
unless user specifies it through dlvCwd. So users still need to
chase them unless they set the exclusion rule purely based on
the file base name).
Fixesgolang/vscode-go#1955
1. change ExpectOutputEventProcessExited to accept -1 exit status, this
is a real problem on linux but we don't know how to fix it and we
already have a test in proc for it.
2. change TestNoDebug_AcceptNoRequestButDisconnect to be less picky
about message ordering, all message orderings seem to be fine, there
is no reason to insist on a particular one, since the DAP server is
unable to actually produce it deterministically.
Fixes#2860
Always load eh_frame section from the executable file instead of the
split debug info file. The eh_frame section is meant to be loaded in
memory along with the executable file so it will usually not be present
in a split debug info file (or, if it is present, it will be the wrong
one).
packages
Changes UserCurrent to exclude frames stopped inside the 'internal' and
'runtime/internal' packages of the standard library.
Before this change a goroutine blocked accepting or reading from a
socket would be reported as having a user current frame of:
internal/poll.runtime_pollWait
After this change accepting goroutines will be reported with a user
current frame of:
net.(*netFD).accept
and reading goroutines as:
net.(*netFD).read
* dap: support 'Env' attribute for launch requests
Env is applied in addition to the delve process environment
variables. The env setting is done by calling os.Setenv
as early as possible when a Launch request is received.
Prior discussion is in https://github.com/go-delve/delve/pull/2582
In Visual Studio Code, setting null for an environment variable
in launch.json or tasks.json indicates users want to unset
the environment variable. Support the behavior by accepting
nil value.
* dap: Env field itself can be omitempty
* edit comment
* service/debugger: disable breakpoints with hitcond not satisfiable
To avoid slowing down the debugged process unnecessarily, we disable
breakpoints with a hit condition that can no longer be hit again.
* test: add integration tests for hit conditions no more satisfiable
* proc/test: fix typo in breakpoints related tests
* test: use the new API for hitcond integration tests
* 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.
* go.mod: update golang.org/x/tools to v0.1.8
Fixes TestGeneratedDoc on go1.18
* TeamCity: bump test matrix
Add 1.18 to test matrix. Remove 1.15 from test matrix and from support range.
* proc,tests: update for regabi on arm64 and 386
Make sure that stacktrace registers always contain the PC register of
the current frame, even though the debug_frame rules might not specify
it on architectures that use a link register.
The PC register is needed to look up loclist entries for variable
evaluation.
* goversion: bump maximum supported Go version to 1.18
* proc: disable asyncpreempt on linux/arm64
Asyncpreempt on linux/arm64 can sometimes restart a sequence of
instructions which will make breakpoint appear to be hit twice in some
cases.
When printing breakpoints on generic functions use the function name
without parameters instead of using the name of the first instantiation
that appears on the list.
* service/debugger: fix bug internal err with Restart on recorded target
If Restart is called after a Continue and Rewind on a recorded target
that has already terminated it will return an internal error.
* proc/gdbserial: allow rewind to work after process exit with rr
It is sometimes useful to set breakpoints and rewind a terminated
process when using rr, for example if interested in the last execution
of some function.
RR will not allow a backward continue after the process exit packet has
been sent, however rr will also generate a synthetic SIGKILL right
before process exit.
Treat this packet as a process exit and change some things so both
continuing backwards and setting breakpoints can be done, on recorded
targets, after process exit has been reported.
This is useful to be able to build using Delve's build scripts when
working from within a directory that has been extracted from a source tarball,
or wherever we wouldn't have git history.
This can be invoked as:
```
go run _scripts/make.go build --no-git
```
Fix signal handling during thread single stepping so that signals that
are generated by executing the current instruction are immediately
propagated to the inferior, while signals other signals sent to the
thread are delayed until the full resume happens.
Fixes a bug where a breakpoint set on an instruction that causes a
SIGSEGV would make Delve hang and a bug where signals received during
single step would make it look like an instruction is executed twice.
Fixes#2801Fixes#2792
Add some dummy go files so that 'go mod vendor' works for modules that
require Delve, becuase directories that do not contain any go code will
not be vendored.
