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
Detect calls that do not target a function's entrypoint
(i.e, calls to runtime.duffzero and runtime.duffcopy) and
instead step into them directly. StepInto sets a breakpoint
past the called function's prologue and expects that continue
will hit that breakpoint, but because the call is into the
interior of the function (well past the prologue) this fails.
Fixes#573
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
This function was broken for a very long time until the changes in this
PR fixed it. However I do not think it is desirable to be catapulted
into some other goroutine by 'next' just because that other goroutine
happened to receive a message on a channel.
This feature should be implemented by a new command, not next.
Previously Next would step through the goroutine associated with
CurrentThread if SelectedGoroutine was parked
Also fixes a bug with proc.(*Process).StepInto where StepInto could
switch to a different goroutine.
* tests: update to cope with go1.7 SSA compiler
* de-vendored golang.org/x/debug/dwarf
We need our own tweaked version
* dwarf/debug/dwarf: always use the entry's name attribute
Using the name attribute leads to better type names as well as fixes
inconsistencies between 1.5, 1.6 and 1.7.
* proc: Updated loadInterface to work with go1.7
go1.7 changed the internal representation of types, removing the string
field from runtime._type.
Updated loadInterface to use the new str field.
* 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.
* proc: add tests for command-line arguments
adds tests to make sure command-line arguments are passed to Launch() properly
* proc_windows: pass command-line arguments to CreateProcess()
build command-line arguments according to how the standard library does it and pass the command line along to the actual syscall on Windows.
see discussion in #479
* proc: better testing of cmd-line arguments
* proc_windows: fix a possible error-case with passing just 1 argument
previously, the command line pointer passed to sys.CreateProcess was empty, if we had 0 parameters (len(cmd) == 1, as cmd[0] is the executable, so no cmdlineGo would be created, while with any argument it would as len(cmd) > 1). This might cause problems down the road, so make sure we include the command line every time, even if it seems to work without.
* proc: improve testing of command-line arguments
test that arguments with spaces are passed on correctly and DRY failure/success condition checking in the args test
- 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
Unrelated to conversion, I have also changed (*Thread).readMemory
to return only first count bytes of memory just as advised
by ReadProcessMemory.
Fixes#409Fixes#412Fixes#416
