* Support --output for debug, trace, and test commands
With the `--output` parameter you can configure the output binary. For
example:
dlv debug --output /tmp/xxx
Will build the binary to `/tmp/xxx`, instead of always putting it as
`debug` in the current directory.
This ensures that the command always works (even if there is already a
file or directory named `debug`) and doesn't write to the source
directory. Especially for things like Delve/Vim integration this is a
good thing to have, I think.
* Address PR feedback and add a test
- We don't need to use `filepath.IsAbs()` on startup; I added that
because it previously did `"./" + debugname` everywhere, but I don't
think that's needed at all, since `pathname` without a leading `./`
implies the current directory.
- Repurpose the existing `TestIssue398` to also test the `--output`
flag. Also fix an issue where tests wouldn't work if `GOPATH` has
multiple entries (e..g `GOPATH=$HOME/go:$HOME/mygocode`).
- Print an error if we can't remove the debug binary on exit instead of
failing silently. Not strictly related to this PR, but a good change
to add I think.
* Also warn when delve can't remove the binary in test/trace
I only added that to debug, but good to issue this warning consistently.
By specifying the -a flag we insure that all packages are recompiled
with -gcflags='-N -l'. Previously -a could not be specified because the
compiler could not compile runtime without optimizations.
Fixes#738
Mozilla RR will create a trace directory that can be reused with the
replay verb, however if we delete the executable file the trace
directory will become useless, so delete that too before exit.
Users that wish to reuse a recording should build the executable
themselves and then use either dlv exec or rr record to do the
recording.
* proc/native: make sure debugged executable can be deleted on windows
Delve opens debugged executable to read binary info it
contains, but it never closes the file. Windows will not
let you delete file that is opened. So close Process.bi
in Process.postExit, and actually call Process.postExit
from windows Process.Kill.
Also Windows sends some debugging events
(EXIT_PROCESS_DEBUG_EVENT event in particular) after Delve
calls TerminateProcess. The events need to be consumed by
debugger before debugged process will be released by
Windows. So call Process.waitForDebugEvent after
TerminateProcess in Process.Kill.
Fixes#398
* cmd/dlv: make TestIssue398 pass on darwin
* cmd/dlv: add comment for TestIssue398
* proc/native: wait for debuggee to exit before returning from windows Process.Kill
* proc/native: close process handle before returning from windows killProcess
* proc/native: remove not used Process.Process
* Fix various issues detected by megacheck
I've ran honnef.co/go/tools/cmd/megacheck and fixed a few of the
things that came up there.
* Cleanup using Gogland
* cmd/dlv: fall back to go env GOPATH when GOPATH envvar is unset.
Since Go 1.8, GOPATH environment variable has a default value if the
environment variable is unset so not setting GOPATH is perfectly ok.
Depend on `go env` command to query Go related environment variable.
* build: update references to moved packages
Sometimes windows will send us events about breakpoints we have
already removed from the code despite the fact that we go to great
lengths to avoid this already.
Change waitForDebugEvent to check that when we receive a breakpoint
event the corresponding memory actually contains an INT 3
instruction, if it doesn't ignore the event and restart the thread.
* proc: Add `wd` to Launch
This change adds the `wd` arg which specify working directory of the
program.
Fixes#295
* service/debugger: Add `Wd` field to debugger.Config
This change adds the `Wd` field which specify working directory of the
program launched by debugger.
Fixes#295
* service: Add `Wd` to service.Config
This change adds the `Wd` field which specify working directory of the
program debugger will launch.
Fixes#295
* cmd/dlv: Add `Wd` flag
This change adds `Wd` flag which specify working directory of the
program which launched by debugger.
Fixes#295
* only set the Linux working directory if it is set,
stub out param in darwin and windows
* set working directory for Windows
https://godoc.org/golang.org/x/sys/windows#CreateProcesshttps://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
* Windows workingDir must be an *uint16
* attempt to chdir on darwin via @yuntan
* proc/exec_darwin.c: fix working directory for darwin
* Add tests to check if working directory works.
* Fix darwin implementation of fork/exec, which paniced if
child fork returned.
* cmd, service: rename Wd to WorkingDir
Allows quoted substrings in build-flags flag. This fixes a build
problem on windows where the default build flags must contain a space.
Fixes#634 and #638
This version preserves the order of requests, allows the
client to switch between API versions and introduces a
way to send notifications to the client (see TODO item at:
proc/proc_linux.go:325).
Fixes#523, #571
This provides a better error message when the user tries to run dlv
debug on a directory that does not contain a main package, when `dlv
exec` is used with a source file.
Additionally the architecture of the executable is checked as suggested
by @alexbrainman in #443.
Fixes#509
* service/api: Removed unused fields of service/api.Function
* proc/eval: Set return variable name to input expression
* all: fine-grained control of loadValue for better variable printing
Makes proc.(*Variable).loadValue loading parameters configurable
through one extra argument of type LoadConfig.
This interface is also exposed through the API so clients can control
how much of a variable delve should read.
New API version with better backwards compatibility plus mechanism to
select the API version that a headless instance should use.
Adds service/test/cmd/typecheckrpc.go to type check the RPC interface.
Implements extensible mechanism to specify which commands accept
prefixes (goroutine, frame, on) instead of hardcoding them in
a switch.
Implements #240
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`.
This patch allows certain commands (`debug`, `test`, and `trace`) to
take an argument specifying a package name. This allows a user to
specify a package other than that of the current package in the working
directory.
If a package name is not specified, the behavior remains the same, as in
Delve will look in the current working directory for a `main` package to
compile.
Fixes#423
This change addresses a Windows-specifc issue with the 'test' command. On
Windows, 'go test' generate executables with a '.exe' filename extention,
but the current implementation attaches to a filename without the
extention.
The 'source' command reads the file specified as argument and executes
it as a list of delve commands.
Additionally a flag '--init' can be passed to delve specifying a file
containing a list of commands to execute on startup.
Issue #96
This renaming avoids confusion with the 'run' subcommand in the go tool.
The 'run' subcommand in Delve is now deprecated. It is still there,
however simply prints a deprecation notice and exits.
Instead of maintaining two separate client / server implementations,
maintain only the more lightweight JSON-RPC service. The reasoning
behind the merging of the original HTTP service was ease of tooling, in
other words low barrier of entry for external clients (editor
integrations, etc...).
I believe the JSON-RPC solution still satisfies that constraint while
have the advantage of being a more lightweight solution. HTTP, while
highly supported in most modern languages, carries with it too many
features we would never take advantage of. The RPC architecture seems
a more natural approach.
The infrastructure set up during the initial HTTP service implementation
was leveraged in the JSON-RPC implementation, so if any of those
original authors are reading this commit message: thank you for that
work, it was not in vain even if though the original HTTP service is not
being removed.
Refactor to introduce client/server separation, including a typed
client API and a HTTP REST server implementation.
Refactor the terminal to be an API consumer.
Notable changes:
* OS X support
* Pure Go readline library
* Fixes issues debugged cgo enabled programs
* Substantial refactoring / code cleanup
Fixes#3#29#70
First of a few refactors to allow multiple clients / frontends for
Delve. Current implementation now uses a cli client, but conceivably we
could have an http or socket based client as well.
