* service/dap: send 'continued' event on next/step/stepout requests
Next/step/stepout requests assume that execution is only resumed
on the thread that was specified. We cannot resume execution on
only a single thread, so we need to send a continued event to let
the client know that all threads have resumed.
* update set breakpoints test with continued event
* service/dap: support pause request
* service/dap: validate the client configurations in initialize request (#2435)
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.
* TeamCity: fix Windows builds (#2467)
Bintray is shutting down and the URL we used to install mingw is no
longer available. Use chocolatey instead.
* proc/native: low level support for watchpoints in linux/amd64 (#2301)
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
* simplify pause test
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
Co-authored-by: Suzy Mueller <suzmue@golang.org>
Co-authored-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Handle the signaled status for the thread leader like we handle the
exited status, by returning ErrProcessExited and recording the killer
signal in it.
Prior to this commit we would find out about the death of the thread
later in the loop, the condition would still be reported as
ErrProcessExited, but without recording the signal number anywhere.
Also fixes a bug in TestAttachStopOnEntry where the test would
inadvertently cause a SIGPIPE to be sent to the target process, making
it terminate early.
* service/dap: implement exception info
* remove adding additional thread
* Fix tests
* add exceptionInfo tests
* update comments
* map paths to client paths
* remove launch.json
* remove change to ConvertEvalScope
* correct name of supportsExceptionInfoRequest
* Add TODO for deleting output event
* Print Stack header to buffer
* Try to move resolving exception info to onExceptionInfoRequest
* save the error and return if it is the current thread
* rename thread to g
* findgoroutine returns goroutine
* clean up findgoroutine
* log errors
* remove output event
* fix grammar
* 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
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.
* 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/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
* 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
* 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
* 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/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>
* 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>
* 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>
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
* 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>
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?).
