* service/dap: support setting breakpoints while running
* Review comments, faster test
* Fix comments
* Address review comments
* Do not continue automatically
* Add TODO to resume exeuction
* Handle async test messages in either order
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* service/dap: add type information to dap variables
* add comment explaining map type choice
* rename to setClientCapabilities
* respond to review
* update TypeString definition
Adds the low-level support for watchpoints (aka data breakpoints) to
the native linux/amd64 backend.
Does not add user interface or functioning support for watchpoints
on stack variables.
Updates #279
daptest has type assertion functions that panic
if the read response/event message is not
the expected type. This is not only against the
recommended style guideline (Don't Panic, Useful
Test Failures, ...), but also it prevents from
quickly diagnosing test failures occurred in remote
CIs.
This PR changes the type assertion to the two
return value type assertion, and t.Fatal with details
if the type is not expected.
service/dap/daptest/main.go is a program that auto
generates those assertion functions in resp.go.
Run `go generate` from the service/dap directory
to update resp.go.
The client can specify certain configurations in the initialize request.
For example, pathFormat determines the pathFormat. We do not currently
support configuring pathFormat, linesStartAt1, or columnsStartAt1, so
we report an error if the client attempts to set these to an
unsupported value.
Changes the expression evaluation code so that register names, when not
shadowed by local or global variables, will evaluate to the current
value of the corresponding CPU register.
This allows a greater flexibility with displaying CPU registers than is
possible with using the ListRegisters API call. Also it allows
debuggers users to view register values even if the frontend they are
using does not implement a register view.
* service/dap: add go build stderr to error response
* service/dap: add go build stderr to error response
* Skip message check for build errors
* test for flag provided message
* service/dap: annotate shadowed variable names in variables request
In order to distinguish variables that are shadowed, this change
updates the names from 'name' to '(name)'. This is the same syntax
used in the terminal package.
* remove unnecessary comment
* Add todo for evaluate name
* Check the evaluateName result is the unshadowed var
* service/rpcommon: resolve race between Detach and shutdown
Detach will close DisconnectChan causing the server to initiate
shutdown, there is a race between Detach writing its response to the
client and the shutdown terminating the server process.
If Detach loses the race the response to the Detach request is never
sent to the client and the client will report an EOF error instead.
This change delays the start of the shutdown process until after Detach
has written its response.
Fixes an occasional failure of TestContinue.
* service/rpccommon: ignore listener error when shutting down
Ignore the closed listener error when the server is being shut down in
response to a SIGINT signal.
Fixes#1633
* service/dap: add substitutePath configuration
Similar to substitute-path configuration in the dlv cli, substitutePath
in dap allows users to specify path mappings that are applied to the
source files in stacktrace and breakpoint requests.
Updates #2203
* service/dap: refactor the startup of the fixture for attach
Add a helper function for starting up a process to attach to.
* service/dap: update substitute path tests for windows
* service/dap: remove lines that should have been removed in merge
* respond to comments on pr
* move logging to helper functions
* make test comments more clear
* Add comments about absolute paths
* fix log messages
* clarify test comments
* remove comment about absolute paths
We have some places where we use proc.ErrProcessExited and some places
that use &proc.ErrProcessExited, resulting in checks for process exited
errors occasionally failing on some architectures.
Uniform use of ErrProcessExited to the non-pointer version.
Fixes intermittent failure of TestStepOutPreservesGoroutine.
When restarting we must take care of setting breakpoint IDs correctly
so that enabled breakpoints do not end up having the same ID as a
disabled breakpoint, also we must make sure that breakpoints created
after restart will not get an ID already used by a disabled breakpoint.
* dap: change how noDebug launch request is served
PR #2400 added support for noDebug launch requests - that was done
by directly starting the target program using os/exec.Cmd and blocking
the launch request indefinitely until the program terminates or
is stopped with a disconnect request (when dlv dap can support it).
Even though the approach seemed to work for user, that adds an extra
control flow and complexity to the codebase.
This change takes a different approach to implement the noDebug
launch feature. Instead of using os/exec.Cmd, this uses the existing
debug launch path, but avoids setting breakpoints. Finally, the program
will start upon receiving onConfigurationDoneRequest and blocks there
until the program terminates. This simplifies the code.
The DAP spec does not explicitly specify what to do about other
requests. It seems like VSCode can issue evaluate requests or other
requests after the configuration done request. Currently they are
blocked because the program is in running state. We can consider checking
s.noDebug and responding with an error in the future if we want/need to.
See the log below for a typical DAP request/response sequence:
2021-03-29T01:42:53-04:00 debug layer=dap building binary at /Users/hakim/projects/s/__debug_bin
2021-03-29T01:42:55-04:00 info layer=debugger launching process with args: [/Users/hakim/projects/s/__debug_bin]
2021-03-29T01:42:55-04:00 debug layer=dap [-> to client]{"seq":0,"type":"event","event":"initialized"}
2021-03-29T01:42:55-04:00 debug layer=dap [-> to client]{"seq":0,"type":"response","request_seq":2,"success":true,"command":"launch"}
2021-03-29T01:42:55-04:00 debug layer=dap [<- from client]{"seq":3,"type":"request","command":"setBreakpoints","arguments":{"source":{"name":"main.go","path":"/Users/hakim/projects/s/main.go"},"breakpoints":[{"line":9}],"lines":[9]}}
2021-03-29T01:42:55-04:00 error layer=dap Unable to set or clear breakpoints: running in noDebug mode
2021-03-29T01:42:55-04:00 debug layer=dap [-> to client]{"seq":0,"type":"response","request_seq":3,"success":false,"command":"setBreakpoints","message":"Unable to set or clear breakpoints","body":{"error":{"id":2002,"format":"Unable to set or clear breakpoints: running in noDebug mode"}}}
2021-03-29T01:42:55-04:00 debug layer=dap [<- from client]{"seq":4,"type":"request","command":"configurationDone","arguments":{}}
2021-03-29T01:42:55-04:00 debug layer=dap [-> to client]{"seq":0,"type":"response","request_seq":4,"success":true,"command":"configurationDone"}
2021-03-29T01:42:55-04:00 debug layer=debugger continuing
Hello
2021-03-29T01:43:00-04:00 debug layer=dap [-> to client]{"seq":0,"type":"event","event":"terminated","body":{}}
2021-03-29T01:43:00-04:00 debug layer=dap [<- from client]{"seq":5,"type":"request","command":"threads"}
2021-03-29T01:43:00-04:00 debug layer=dap [-> to client]{"seq":0,"type":"response","request_seq":5,"success":true,"command":"threads","body":{"threads":null}}
2021-03-29T01:43:00-04:00 debug layer=dap [<- from client]{"seq":6,"type":"request","command":"disconnect","arguments":{}}
2021-03-29T01:43:00-04:00 debug layer=dap [-> to client]{"seq":0,"type":"response","request_seq":6,"success":true,"command":"disconnect"}
2021-03-29T01:43:00-04:00 debug layer=debugger halting
2021-03-29T01:43:00-04:00 error layer=dap Process 27219 has exited with status 0
2021-03-29T01:43:00-04:00 debug layer=debugger detaching
Updates https://github.com/golang/vscode-go/issues/1111
* service/dap: address polina's comments for noDebug logic
Reworked so the noDebug launch request again blocks launch request
handler after responding with the launch response. By skipping
the initialized event, it should prevent well-behaving clients from
sending any further requests. Currently, doesn't matter because
the handler goroutine will be blocked until the program termination
anyway.
Placed mutex back, since I noticed that's the only way to prevent
racing between Stop and the handler goroutine. The synchronization
lotic (in particular, during teardown) should be revisited after
asynchronous request support work is done.
* dap: address more comments
* service/dap: switch goroutine before stepping
The correct goroutine needs to be selected when stepping in order
for the step to execute to the correct location.
* handle next in progress while stepping
* Add tests for steps when switching goroutine
* remove nextInProgress handling
* add new step out test and review debug state check
* update text of stopped event and set goroutine id
Error level logging shows up in the users' consoles/terminals
so be more conservative when logging. Move the followings to
Debug logging.
- DAP error reponses caused by invalid requests.
They are application level errors and DAP clients should handle them.
- Errors reported when debugee already exited.
Fixesgolang/vscode-go#1392
Changes print so a format argument can be specified by using '%' as
prefix. For example:
print %x d
will print variable 'd' in hexadecimal. The interpretarion of the
format argument is the same as that of fmt's package.
Fixes#1038Fixes#1800Fixes#2159
* Truncate long compound map keys and use address suffix only for those
* Remove test typo that causes failures
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* Add logging and comments to clarify relative output path treatement
* Use absolute output path in one of the unittests
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
If the launch requests has noDebug attribute set, run the built
binary directly. The launch request handler will block until
the binary terminates, so the editor won't send additional requests
like breakpoint setting etc. Still disconnect or restart requests
can flow in though and they should trigger killing of the target
process if it's still running.
In order to run the binary using os/exec on windows, the target
binary has to have .exe as its extension. So, add .exe to the default
output name if it is on windows. I am not sure though yet we want
to modify the user-specified output or not yet. Considering how
go commands behave (not automatically append .exe for 'go build -o')
I think respecting what user specified is right, but the failure
(file not exist) may be mysterious.
* service/dap: use specified working directory for launch requests
If a user specifies a working directory in the launch request,
then the process should use that working directory. This may
affect how the program runs and the user should be able to have
control over this.
* service/dap: add tests for launch with working dir
Added tests to make sure the working directory is set correctly.
* service/dap: fix TestWorkingDir on windows
* service/dap: use %q to print quoted string
* cmd/dlv: update dap warning about working dir
* service/dap: change the launch argument to be wd`
* update warning to specify only launch request
* Adds toggle command
Also adds two rpc2 tests for testing the new functionality
* Removes Debuggers' ToggleBreakpoint method
rpc2's ToggleBreakpoint now calls AmendBreakpoint
Refactors the ClearBreakpoint to avoid a lock.
* Use (*api.Variable).SinglelinesString() for dap.Variable values
* Make DeepSource happy
* Adjust unreadable regex in tests
* Use regex for runtime.mutex variable test
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* service: serialize calls to Command API
Wait until the target process has resumed before accepting new calls to
Command. Before this if a 'continue' was immediately followed by a
'halt' the 'halt' could be processed before the 'continue'.
Fixes#1608Fixes#2216
* service/rpccommon: fix DeepSource issues
* service/dap: support auto-loading of unloaded interfaces
* Make DeepSource happy
* Don't set reference if data failed to auto-load
* Use frame-less expressions
* Refine interface recursion capping test case
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
- remove github workflow for testing macOS/amd64 that is now covered by
TeamCity
- fix DeepSource glob patterns to actually match what they are intended
to match (did the interpretation change?)
- disable some cgo tests on darwin/arm64
* Avoid double removal of temp binary
* Add back accidentally removed empty line
* Simplify regex
* Use unique build output directories in test cases
* Recover TestLaunchDebugRequest hidden logging and refine error check
* Special case access-denied error on Windows
* Remove special case for access denied on Windows
* Increase remove delay on Win
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* TeamCity: add linux/arm64/tip configuration
So that it can be tested when we make the next-version-support-branch.
* tests: disable failing cgo tests on arm64
* DAP test for github.com/golang/vscode-go/issues/1056
* DAP test for github.com/golang/vscode-go/issues/884
* DAP test for github.com/golang/vscode-go/issues/851
* DAP test for github.com/golang/vscode-go/issues/1053
* DAP test for github.com/golang/vscode-go/issues/1054
* Make DeepSource happy
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* proc/core: off-by-one error reading ELF core files
core.(*splicedMemory).ReadMemory checked the entry interval
erroneously when dealing with contiguous entries.
* terminal,service,proc/*: adds dump command (gcore equivalent)
Adds the `dump` command that creates a core file from the target process.
Backends will need to implement a new, optional, method `MemoryMap` that
returns a list of mapped memory regions.
Additionally the method `DumpProcessNotes` can be implemented to write out
to the core file notes describing the target process and its threads. If
DumpProcessNotes is not implemented `proc.Dump` will write a description of
the process and its threads in a OS/arch-independent format (that only Delve
understands).
Currently only linux/amd64 implements `DumpProcessNotes`.
Core files are only written in ELF, there is no minidump or macho-o writers.
# Conflicts:
# pkg/proc/proc_test.go
Both structMember and findMethod implemented a depth-first search in
embedded fields but the Go specification requires a breadth-first
search. They also allowed promotion of fields in the concrete type of
embedded interfaces even though this is not allowed by Go.
Furthermore they both lacked protection from infinite recursion
when a type embeds itself and the user requests a non-existent field.
Fixes#2316
Changs TestClientServer_FullStacktrace and
Test1ClientServer_FullStacktrace to log more information, also removes
code from TestFrameEvaluation that could mask the error.
Updates #2231
* add -json flag when running tests on TeamCity
* introduce TeamCity builds
* restore gdbserial constants for 386
Otherwise compilation fails.
* skip TestAttachRequest on Windows as it never finishes
* run tests on 1.16beta1
* Add support for evaluateName for variables
* More evaluateName logic tweaks and tests
* Make DeepSource happy
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* Use address, not index to differentiate compound map keys
* Clean up calls to expectVarRegex
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* proc: misc test fixes for Go 1.16
* proc: fix cgo stacktraces in Go 1.16 with simplified C -> Go call path
* dwarf/line: make dwarf/line correct when '\\' are used
Our code depends heavily on paths being '/' separated because go always
produced '/' separated file paths. The call to filepath.Join will
normalize the paths, on windows, to always be '\\' separated, which
violated our assumptions.
This didn't use to be a problem because the codepath that calls
filepath.Join was never exercised by executable files produced by Go,
but Go 1.16 started producing debug_line sections that use the
directory table with https://go-review.googlesource.com/c/go/+/263017/.
Fix this to always use path.Join after making sure, on windows, to
always normalize paths to use '/' as a separator. Replace the use of
filepath.IsAbs with an operating system independent version.
* goversion: bump supported Go version
Fix bug in DAP test: TestEvaluateCallRequest.
In Go 1.15 the call injection will be executed on a different goroutine
from the goroutine where it was started on to avoid confusing the
garbage collector, the test must be aware of this fact and use the
goroutine ID from the stopped response instead of assuming 1 is the
currently selected goroutine.
Disables TestAttachDetach when running in Github Actions.
Disable some coredump tests when running in Github Actions (core size
limits?).
evalFunctionCall needs to remove the breakpoint from the current thread
after starting the function call injection, otherwise Continue will
think that the thread is stopped at a breakpoint and return to the user
instead of continuing the call injection.
Adds a flag that distinguishes the return values of an injected
function call from the return values of a function call executed by the
target program.
On linux we can not read memory if the thread we use to do it is
occupied doing certain system calls. The exact conditions when this
happens have never been clear.
This problem was worked around by using the Blocked method which
recognized the most common circumstances where this would happen.
However this is a hack: Blocked returning true doesn't mean that the
problem will manifest and Blocked returning false doesn't necessarily
mean the problem will not manifest. A side effect of this is issue
#2151 where sometimes we can't read the memory of a thread and find its
associated goroutine.
This commit fixes this problem by always reading memory using a thread
we know to be good for this, specifically the one returned by
ContinueOnce. In particular the changes are as follows:
1. Remove (ProcessInternal).CurrentThread and
(ProcessInternal).SetCurrentThread, the "current thread" becomes a
field of Target, CurrentThread becomes a (*Target) method and
(*Target).SwitchThread basically just sets a field Target.
2. The backends keep track of their own internal idea of what the
current thread is, to use it to read memory, this is the thread they
return from ContinueOnce as trapthread
3. The current thread in the backend and the current thread in Target
only ever get synchronized in two places: when the backend creates a
Target object the currentThread field of Target is initialized with the
backend's current thread and when (*Target).Restart gets called (when a
recording is rewound the currentThread used by Target might not exist
anymore).
4. We remove the MemoryReadWriter interface embedded in Thread and
instead add a Memory method to Process that returns a MemoryReadWriter.
The backends will return something here that will read memory using
the current thread saved by the backend.
5. The Thread.Blocked method is removed
One possible problem with this change is processes that have threads
with different memory maps. As far as I can determine this could happen
on old versions of linux but this option was removed in linux 2.5.
Fixes#2151
* service/rpccommon: log error for conns rejected by --only-same-user
If no logger is enabled manually write to stderr instead.
Fixes#2209
* logflags: fix style complaints from DeepSource
* service/dap: add "panic" and "fatal error" as stopped reasons
The unrecovered panic and fatal throw breakpoints are not set by the
user. We now check for these special breakpoints and send appropriate
stopped reasons to the client.
* Add getter for StopReason
* Set threadID and stop reason correctly
If there is no selected goroutine, no goroutine ID should be set in
the stopped event.
The stopped reason can be better determined using the process
StopReason.
* Update panic breakpoint on next test to work with Go 1.13 runtime
When running panic.go with Go1.13, the next line that is stepped to
after panic('boom') is the defer function in the runtime package. The
unrecovered panic breakpoint is not hit until after several steps.
The test now steps until the breakpoint is hit, or the program terminates
without hitting the unrecovered panic breakpoint, in which case it fails.
* Skip breakpoint on next test in < Go 1.14
* Add underlying type when printing interface type
* Add todo to remove one level from interface printing
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* Travis-CI: add ignorechecksum option to chocolatey command
Looks like a configuration problem on chocolatey's end.
* service/*: remove threadID argument of (*Debugger).PackageVariables
Which thread is used doesn't make any difference to the list of package
variables that is returned and this option was only ever used by an old
v1 API call.
* Support global variables
* Respond to review comments
* Clarify comment
* Add more details to test error messages
* Remove flaky main..inittask checks
* Rename globals flag to match vscode-go
* Normalize filepath with slash separator
* Improve handling for unknown package
* Tweak error message
* More refactoring, normalization and error details to deal with Win test failures
* Clean up optional launch args processing
* Add CurrentPackage to debugger and use instead of ListPackagesBuildInfo
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
Move the conversion of some 'proc' types from service/debugger into
service/rpc1 and service/rpc2. The methods of
service/debugger.(*Debugger) are also used by service/dap which
requires these types to be converted differently and converting them
twice is inefficent and doesn't make much sense.
Updates #2161
Since proc is supposed to work independently from the target
architecture it shouldn't use architecture-dependent types, like
uintptr. For example when reading a 64bit core file on a 32bit
architecture, uintptr will be 32bit but the addresses proc needs to
represent will be 64bit.
Adds features to support default file descriptor redirects for the
target process:
1. A new command line flag '--redirect' and '-r' are added to specify
file redirects for the target process
2. New syntax is added to the 'restart' command to specify file
redirects.
3. Interactive instances will check if stdin/stdout and stderr are
terminals and print a helpful error message if they aren't.
Recent changes to the way registers are handled broke reporting of AVX
registers (i.e. YMMx). This change restores the functionality by:
- concatenating the higher half of the YMMx registers to their
corresponding XMMx lower half (YMMx registers do not have an
independent DWARF register number)
- modifying the formatSSEReg function to handle them when they are
present.
Fixes#2033
Commit 1ee8d5c reviewed in Pull Request #1960 relaxed some tests using
goroutinestackprog but missed others.
Fixes some test flakiness that isn't relevant.
