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
Step disassembles the current instruction, if it is a CALL sets a
temp breakpoint inside the called function, after the prologue and
calls Continue.
Fixes#332
- Unlike FunctionEntryToFirstLine can skip the prologue on functions
that are defined on a single line, either because they weren't
formatted or because they were autogenerated
- Can skip the prologue on most functions when setting a breakpoint
with the filename:line syntax
Fixes#396
1. A running goroutine is by definition not parked waiting for a
chan recv
2. The FDE end address is intended to be exclusive, the code
interpreted as inclusive and sometimes ended up setting a breakpoint
on a function other than the current one.
Past the maximum recursion depth maps shouldn't be loaded at all,
adding map children and not loading them breaks assumptions in
the prettyprinter.
Fixes#406
If uninitialized memory is read loadArrayValues could try to call
cacheMemory with a negative size, which could cause a 'makeslice:
len out of range' panic.
Fixes#354 (partial)
