* service/debugger: Restore breakpoints using file:line on restart
Restoring by address can cause the breakpoint to be inserted in the
middle of an instruction if the executable file has changed.
* terminal: Warn of stale executable when printing source
* 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
Instead of repeatedly calling StepInstruction set breakpoints to the
destination of CALL instructions (or on the CALL instructions
themselves for indirect CALLs), then call Continue.
Calls to unexported runtime functions are skipped.
Reduces the number of code paths managing inferior state from 3 to 2
(StepInstruction, Continue).
Fixes#561
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
* proc: bugfix: StepInto can not function when temp bps exist
* terminal,service: auto-continue during next and step
Make dlv call continue automatically when a breakpoint is hit on a
different goroutine during a next or step operation.
Added API hooks to implement the other solution to this problem (cancel
the next/step operation if a different breakpoint is hit).
Fixes#387
* 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.
- made GoroutineStacktrace a method of struct G
- made stacktrace a method of StackIterator
- renamed StackIterator to stackIterator
- factored out logic to obtain a stackIterator from a goroutine that's
used by both (*G).Stacktrace and by (*G).UserCurrent
proc.(*Process) methods are not thread safe, multiple clients
connecting simultaneously to a delve server (Issue #383) or a even
a single over-eager client (Issue #408) can easily crash it.
Additionally (Issue #419) calls to client.(*RPCClient).Halt can
crash the server because they can result in calling the function
debug/dwarf.(*Data).Type simultaneously in multiple threads which
will cause it to return incompletely parsed dwarf.Type values.
Fixes#408, #419 (partial)
Location specifiers starting with '*' can be followed by any
expression supported by the evaluator.
The expression should evaluate to either an integer (which will be
interpreted as an address) or to a function pointer (which will be
dereferenced to get the function's entry point).
Next sets its temporary breakpoints with the condition that they
must only activate on the current goroutine, and then calls Continue
When Continue encounters a temporary breakpoint it clears all
the breakpoint.
User visible changes: breakpoints that get hit while executing Next
are not ignored.
This commit does not implement full conditional breakpoints
functionality, the only condition that can be set is on the
goroutine id.
Fixes race conditions in Next affecting TestNextConcurrent.
Use proc.(*Process).FindGoroutine in proc.(*Process).SwitchGoroutine and
debugger.(*Debugger).Stacktrace. That method did not exist when those
were originally written.
Breakpoints, tracepoints, etc.. take a location spec as input. This
patch improves the expressiveness of that API. It allows:
* Breakpoint at line
* Breakpoint at function (handling package / receiver smoothing)
* Breakpoint at address
* Breakpoint at file:line
* Setting breakpoint based off regexp
Previously either the terminal client or the debugger service would
either lock main goroutine to a thread or provide a locked goroutine to
run _all_ DebuggedProcess functions in. This is unnecessary because only
ptrace functions need to be run from the same thread that originated the
PT_ATTACH request.
Here we use a specific thread-locked goroutine to service any ptrace
request. That goroutine is also responsible for the initial spawning /
attaching of the process, since it must be responsible for the PT_ATTACH
request.
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.
