* 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
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)
- 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
Typedefs that resolve to slices are not recorded in DWARF as typedefs
but instead as structs in a way that there is no way to know they
are really slices using debug/dwarf.
Using golang.org/x/debug/dwarf instead this problem is solved and
as a bonus some types are printed with a nicer names: (struct string
→ string, struct []int → []int, etc)
Fixes#356 and #293
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).
Prefetch the entire memory of structs and arrays and cache it instead
of issuing readMemory calls only when we get down to primitive types.
This reduces the number of system calls to ptrace that variables makes.
Improves performance in general, greatly improving it in some
particular cases (involving large structs).
Benchmarks without prefetching:
BenchmarkArray-4 10 132189944 ns/op 0.06 MB/s
BenchmarkArrayPointer-4 5 202538503 ns/op 0.04 MB/s
BenchmarkMap-4 500 3804336 ns/op 0.27 MB/s
BenchmarkGoroutinesInfo-4 10 126397104 ns/op
BenchmarkLocalVariables-4 500 2494846 ns/op
Benchmarks with prefetching:
BenchmarkArray-4 200 10719087 ns/op 0.76 MB/s
BenchmarkArrayPointer-4 100 11931326 ns/op 0.73 MB/s
BenchmarkMap-4 1000 1466479 ns/op 0.70 MB/s
BenchmarkGoroutinesInfo-4 10 103407004 ns/op
BenchmarkLocalVariables-4 1000 1530395 ns/op
Improvement factors:
BenchmarkArray 12.33x
BenchmarkArrayPointer 16.97x
BenchmarkMap 2.59x
BenchmarkGoroutinesInfo 1.22x
BenchmarkLocalVariables 1.63x
Breakpoints are skipped either because:
1. when multiple breakpoints are hit simultaneously only one is
processed
2. a thread hits a breakpoint while another thread is being
singlestepped over the breakpoint.
Additionally fixed a race condition between Continue and tracee
termination.
The concrete type of an interface only contains the abbreviated
package name, we must construct a map from package names to package
paths to be able to resolve the concrete type of an interface.
Supported operators:
- All (binary and unary) operators between basic types except <-,
++ and -- (includes & to take the address of an expression)
- Comparison operators between supported compound types
- Typecast of integer constants into pointer types
- struct members
- indexing of arrays, slices and strings
- slicing of arrays, slices and strings
- pointer dereferencing
- true, false and nil constants
Implements #116, #117 and #251
Instead of trying to be clever and make an 'educated guess' as to where
the flow of control may go next, simple do the more naive, yet correct,
approach of setting a breakpoint everywhere we can in the function and
seeing where we end up. On top of this we were already setting a
breakpoint at the return address and deferred functions, so that remains
the same.
This removes a lot of gnarly, hard to maintain code and takes all the
guesswork out of this command.
Fixes#281
Embedded structs are encoded in DWARF as fields with
package-qualified names. They define an anonymous field
on the struct with the non-qualified name, as well as
promoted fields for each field of the embedded struct so
long as these are not shadowed by fields of the containing
struct.
Fixes#220.
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
Support multiple file / directory tables for multiple compilation units.
- added a type DebugLines that can hold number of DebugLineInfo
- added a supporting attribute to DebugLineInfo called 'Lookup' which is to be
used to quickly lookup if file exists in FileNames slice
- added supporting methods to lookup and return corresponding DebugLineInfo
- changed the debug_line parsing behavior to read all the available tables and
push them to DebugLines
- since Process.lineInfo is now a slice, it was breaking AllPCsBetween as well
- updated that function's definition to accept a new filename parameter to be
able to extract related DebugLineInfo
- updated calls to AllPCsBetween
- fixed tests that were broken due to attribute type change in Process
- updated _fixtures/cgotest program to include stdio.h, so that it updates
.debug_line header
- added a test to check 'next' in a cgo binary
- OSX - 1.4 does not support cgo, handle that in new testcase
This patch aims to improve how Delve tracks the current goroutine,
especially in very highly parallel programs. The main spirit of this
patch is to ensure that even in situations where the goroutine we care
about is not executing (common for len(g) > len(m)) we still end up back
on that goroutine as a result of executing the 'next' command.
We accomplish this by tracking our original goroutine id, and any time a
breakpoint is hit or a threads stops, we examine the stopped threads and
see if any are executing the goroutine we care about. If not, we set
'next' breakpoint for them again and continue them. This is done so that
one of those threads can eventually pick up the goroutine we care about
and begin executing it again.
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
Instead of fighting against the normal flow, just signal a SIGTRAP and
let the existing flow handle it, as long as we set the halt flag
correctly the system should halt.
Remove any assumption that a wait syscall on a thread id after a
continue will return. Any time we continue a thread, wait for activity
from any thread, because the scheduler may well have switched contexts
on us due to syscall entrace, channel op, etc...
There are several more things to be done here including:
* Potential tracking of goroutine id as we jump around to thread
contexts.
* Potential of selectively choosing threads to operate on based on the
internal M data structures, ensuring that our M has an active G.
This commit partially fixes#23 and #24, however there are still some
random hangs that happen and need to be ironed out.
Areas that need improving:
* Code cleanup
* Promote breakpoints back out of thread context
* Fix potential bug in "Next" implementation, when thread contexts
switch
Once the program detects that we have stepped into another function,
we simply calculate the return address and then set a breakpoint and
continue to that location, avoiding numerous syscalls.
Improvements:
* `next`ing through a loop works correctly (when not already within a loop)
* `next`ing out of a function works correctly
Needs work:
* `next`ing in a loop can be improved when starting within a loop
This current implementation does not cover the following:
* Setting correct breakpoint when exiting loop
* Setting correct breakpoint when returning from function
* All facilities are available for this, it just is not taken into
account in the current `next` implementation.
Implement basic api for figuring out, given a current PC value, where
the function will return. Currently the API provides only a way to
determine the offset from SP (the Canonical Frame Address). It is left
up to the caller to grab the actual address from the traced program.
