Some tests used a fake vendor directory placed inside _fixtures to
import some support packages.
In go.mod mode vendor directory are only supported on the root of the
project, which breaks some of our tests.
Since vendor directories outside the root of the project are so rare
anyway it's possible that a future version of go will stop supporting
it even in GOPATH mode.
Also it was weird and unnecessary in the first place anyawy.
Continue did not resume execution after a call to CallFunction if the
point where the process was stopped, before the call CallFunction, was
a breakpoint.
Fixes#1374
With this syntax users do not need to type the concrete type of an
interface variable to access its contents. This also sidesteps the
problem where the serialization of a type by go/printer is different
from the one used for debug_info type names.
Updates #1328
Normally variables that have a named struct as a type will get a
typedef entry as their type, sometimes however the Go linker will
decide to use the DW_TAG_structure_type entry instead.
For consistency always wrap a struct type into a typedef when we are
creating a new variables (see comment in newVariable for exceptions).
This fixes a bug where it would be impossible to call methods on a
global variable.
Evaluates var.method expressions into a variable holding the
corresponding method with the receiver variable as a child, in
preparation for extending CallFunction so that it can call methods.
Changes (*Variable).setValue so that it can be used in CallFunction to
set up the argument frame for the function call, adding the ability to:
- nil nillable types
- set strings to the empty string
- copy from one structure to another (including strings and slices)
- convert any interface type to interface{}
- convert pointer shaped types (map, chan, pointers, and structs
consisting of a single pointer field) to interface{}
This covers all cases where an assignment statement can be evaluated
without allocating memory or calling functions in the target process.
Adds -defer flag to the stack command that decorates the stack traces
by associating each stack frame with its deferred calls.
Reworks proc.next to use this feature instead of using proc.DeferPC,
laying the groundwork to implement #1240.
Implements the function call injection protocol introduced in go 1.11
by https://go-review.googlesource.com/c/go/+/109699.
This is only the basic support, see TODO comments in pkg/proc/fncall.go
for a list of missing features.
Updates #119
If the application being debugged imports two packages with the same
name (but different paths) there was no way to disambiguate the two,
since the character '/' can not appear inside a go identifier.
By allowing users to use a string literal as the package name a package
path can be specified.
Displays the return values of the current function when we step out of
it after executing a step, next or stepout command.
Implementation of this feature is tricky: when the function has
returned the return variables are not in scope anymore. Implementing
this feature requires evaluating variables that are out of scope, using
a stack frame that doesn't exist anymore.
We can't calculate the address of these variables when the
next/step/stepout command is initiated either, because between that
point and the time where the stepout breakpoint is actually hit the
goroutine stack could grow and be moved to a different memory address.
Go1.11 uses the is_stmt flag of .debug_line to communicate which
assembly instructions are good places for breakpoints, we should
respect this flag.
These changes were introduced by:
* https://go-review.googlesource.com/c/go/+/102435/
Additionally when setting next breakpoints ignore all PC addresses that
belong to the same line as the one currently under at the cursor. This
matches the behavior of gdb and avoids stopping multiple times at the
heading line of a for statement with go1.11.
Change: https://go-review.googlesource.com/c/go/+/110416 adds the
prologue_end flag to the .debug_line section to communicate the end of
the stack-split prologue. We should use it instead of pattern matching
the disassembly when available.
Fixes#550
type of interfaces
'c7cde8b'.
If dwz binary is available in the system, test delve's ability to find
deduplicated symbols in the DWARF information.
dwzcompression.go contains a small C function (void fortytwo()) which
calls glibc's fprintf with stdin as first argument. Normally, stdin
will be present as a DW_TAG_variable as part of a DW_TAG_compile_unit
named dwzcompression.cgo2.c.
After running dwz on the binary, stdin is moved to a
DW_TAG_partial_unit, which is imported from dwzcompression.cgo2.c with
a DW_TAG_imported_unit.
This test verifies that delve is able to find stdin symbol's type, as a
way to confirm it understands dwz's compressed/deduplicated DWARF
information.
Go 1.10 added inlined calls to debug_info, this commit adds support
for DW_TAG_inlined_call to delve, both for stack traces (where
inlined calls will appear as normal stack frames) and to correct
the behavior of next, step and stepout.
The calls to Next and Frame of stackIterator continue to work
unchanged and only return real stack frames, after reading each line
appendInlinedCalls is called to unpacked all the inlined calls that
involve the current PC.
The fake stack frames produced by appendInlinedCalls are
distinguished from real stack frames by having the Inlined attribute
set to true. Also their Current and Call locations are treated
differently. The Call location will be changed to represent the
position inside the inlined call, while the Current location will
always reference the real stack frame. This is done because:
* next, step and stepout need to access the debug_info entry of
the real function they are stepping through
* we are already manipulating Call in different ways while Current
is just what we read from the call stack
The strategy remains mostly the same, we disassemble the function
and we set a breakpoint on each instruction corresponding to a
different file:line. The function in question will be the one
corresponding to the first real (i.e. non-inlined) stack frame.
* If the current function contains inlined calls, 'next' will not
set any breakpoints on instructions that belong to inlined calls. We
do not do this for 'step'.
* If we are inside an inlined call that makes other inlined
functions, 'next' will not set any breakpoints that belong to
inlined calls that are children of the current inlined call.
* If the current function is inlined the breakpoint on the return
address won't be set, because inlined frames don't have a return
address.
* The code we use for stepout doesn't work at all if we are inside
an inlined call, instead we call 'next' but instruct it to remove
all PCs belonging to the current inlined call.
* Extend the "frame" command to set the current frame.
Command
frame 3
sets up so that subsequent "print", "set", "whatis" command
will operate on frame 3.
frame 3 print foo
continues to work.
Added "up", "down". They move the current frame up or down.
Implementation note:
This changes removes "scopePrefix" mode from the terminal/command.go and instead
have the command examine the goroutine/frame value to see if it is invoked in a
scoped context.
* Rename Command.Frame -> Command.frame.
Registers XMM1 and XMM2 get sometimes clobbered between the time we set
them and the panic. There is no guarantee that they won't in the go
spec so we shouldn't expect any register to keep its value. However
since this seems to only affect 1 and 2 let's try to use 9 and 10
instead.
Every time we read an empty string we accidentally issue a read for 0
bytes at address 0, this is fine for real memory but the core file
reader doesn't like it.
Fixes an issue reported on the mailing list.
If a breakpoint is hit close to process death on a thread that isn't
the group leader the process could die while we are trying to stop it.
This can be easily reproduced by having the goroutine that's executing
main.main (which will almost always run on the thread group leader)
wait for a second goroutine before exiting, then setting a breakpoint
on the second goroutine and stepping through it (see TestIssue1101 in
proc_test.go).
When stepping over the return instruction of main.f the deferred
wg.Done() call will be executed which will cause the main goroutine to
resume and proceed to exit. Both the temporary breakpoint on wg.Done
and the temporary breakpoint on the return address of main.f will be in
close proximity to main.main calling os.Exit() and causing the death of
the thread group leader.
Under these circumstances the call to native.(*Thread).waitFast in
native.(*Thread).halt can hang forever due to a bug similar to
https://sourceware.org/bugzilla/show_bug.cgi?id=12702 (see comment in
native.(*Thread).wait for an explanation).
Replacing waitFast with a normal wait work in most circumstances,
however, besides the performance hit, it looks like in this
circumstances trapWait sometimes receives a spurious SIGTRAP on the
dying group leader which would cause the subsequent call to wait in
halt to accidentally reap the process without noting that it did exit.
Instead this patch removes the call to wait from halt and instead calls
trapWait in a loop in setCurrentBreakpoints until all threads are set
to running=false. This is also a better fix than the workaround to
ESRCH error while setting current breakpoints implemented in 94b50d.
Fixes#1101
If the last entry of the package path contains a '.' the corresponding
DIEs for its types will replace the '.' character with '%2e'. We must
do the same when resolving the package path of the concrete type of an
interface variable.
Fixes#1137
Much like the bug in issue #1031 and commit
f6f6f0bf13e4c708cb501202b83a6327a0f00e31 pointers can also escape to
the heap and then have a zero address (and no children) when we
autodereference.
1. Mark autodereferenced escaped variables with a 0 address as
unreadable.
2. Add guards to the pretty printers for unsafe.Pointer and pointers.
Fixes#1075
* command/terminal: allow restart to change process args
Add -args flag to "restart" command. For example, "restart -args a b c" will
pass args a b c to the new process.
Add "-c" flag to pass the checkpoint name. This is needed to disambiguate the
checkpoint name and arglist.
Reverted unnecessary changes.
* Applied reviewer comments.
Vendored argv.
Change the syntax of restart. When the target is is in recording mode, it always
interprets the args as a checkpoint. Otherwise, it interprets the args as
commandline args. The flag "-args" is still there, to handle the case in which
the user wants to pass an empty args on restart.
* Add restartargs.go.
Change "restart -args" to "restart -noargs" to clarify that this flag is used to
start a process with an empty arg.
When creating a stack trace we should switch between the goroutine
stack and the system stack (where cgo code is executed) as appropriate
to reconstruct the logical stacktrace.
Goroutines that are currently executing on the system stack will have
the SystemStack flag set, frames of the goroutine stack will have a
negative FrameOffset (like always) and frames of the system stack will
have a positive FrameOffset (which is actually just the CFA value for
the frame).
Updates #935
Replace the unsafe.Pointer type of the buf field of channels with the
appropriate array type, allow expressions accessing member field of the
channel struct.
Fixes#962
Conditional breakpoints with unmet conditions would cause next and step
to skip the line.
This breakpoint changes the Kind field of proc.Breakpoint from a single
value to a bit field, each breakpoint object can represent
simultaneously a user breakpoint and one internal breakpoint (of which
we have several different kinds).
The breakpoint condition for internal breakpoints is stored in the new
internalCond field of proc.Breakpoint so that it will not conflict with
user specified conditions.
The breakpoint setting code is changed to allow overlapping one
internal breakpoint on a user breakpoint, or a user breakpoint on an
existing internal breakpoint. All other combinations are rejected. The
breakpoint clearing code is changed to clear the UserBreakpoint bit and
only remove the phisical breakpoint if no other bits are set in the
Kind field. ClearInternalBreakpoints does the same thing but clearing
all bits that aren't the UserBreakpoint bit.
Fixes#844
Adds test command line flag to compile target fixtures using the -race flag.
Multiple tests will fail because of https://github.com/golang/go/issues/22600
but eventually this should work.
1. Use a slice instead of a map to access standard and extended opcodes
(reduces BenchmarkStateMachine from ~12ms/op to ~7ms/op)
2. Cache StateMachine values for the entry point of functions.
* string to []rune
* string to []byte
* []rune to string
* []byte to string
* any pointer to uintptr
The string, []rune, []byte conversion pairs aligns this to the go
language.
The pointer -> uintptr conversion pair is symmetric to the uintptr ->
pointer that we already have.
Also lets the user specify any size for byte array types instead of
just the ones already used by the program, this can be used to read
arbitrary memory.
Fixes#548, #867
If the user tries to list the contents of a function pointer but
forgets the '*' operator the location lookup will fail and result in a
unhelpful "location not found" error.
Instead if the location lookup fails we should try interpreting the
locspec as if it was preceded by '*'.
Before this commit our temp breakpoints only checked that we would stay
on the same goroutine.
However this isn't enough for recursive functions we must check that we
stay on the same goroutine AND on the same stack frame (or, in the case
of the StepOut breakpoint, the previous stack frame).
This commit:
1. adds a new synthetic variable runtime.frameoff that returns the
offset of the current frame from the base of the call stack.
This is similar to runtime.curg
2. Changes the condition used for breakpoints on the lines of the
current function to check that runtime.frameoff hasn't changed.
3. Changes the condition used for breakpoints on the return address to
check that runtime.frameoff corresponds to the previous frame in the
stack.
4. All other temporary breakpoints (the step-into breakpoints and defer
breakpoints) remain unchanged.
Fixes#828
Detach did not work for processes we attach to via PID.
Linux: we were only detaching from the main thread, all threads are
detached independently
Windows: we must resume all threads before detaching.
macOS: still broken.
Updates #772
* service/rpccommon: fixed typo
* proc: test parseG while target is in runtime.deferreturn
runtime.deferreturn will change the value of curg._defer.fn in such a
way that if the target is stopped at just the right instruction it
may crash an incorrect implementation of parseG
* proc/stack: handle stack barriers correctly
Correctly handle stack barriers insterted during garbage collection.
* dwarf/line: bugfix: not all values of the state machine can be used
According to DWARF Version 3 Section 6.2 "Line Number Information" not
all the values transversed by the line numbers state machine are valid
instructions, only the ones after a "special opcode", after the
standard opcode DW_LNS_copy and the extended opcode
DW_LINE_end_sequence.
DWARF3 describes this by specifying that only the opcodes listed above
"append a row to the matrix".
Additionally the implementation of DW_LNS_const_add_pc was wrong.
Fixes#664
* dwarf/line: fixed test failing with go1.8
* service/test: fix prologue detection tests
The conditions about which function prologue is emitted by the compiler
changed in go1.8, changed the test program so that callme2 will still
have a prologue under go1.8.
* service/test: fix step test
compilation units are linked in a different order under go1.8 so the
code of 'fmt' is no longer located after 'main' in the executable,
changed the tests so that they don't rely on this assumption anymore.
* proc: change runtime.Breakpoint support for go1.8
Before 1.8 it was sufficient to step twice to exit a
runtime.Breakpoint(), but go 1.8 added frame pointer tracking to small
functions making runtime.Breakpoint longer.
This changes runtime.Breakpoint handling in Continue to single step as
many times as are needed to exit runtime.Breakpoint.
* proc/test: fix TestIssue561 for go1.8
* service: Prevent panics from crashing delve and killing the target
Catch all unrecovered proc and debugger panics in the service layer and
report them as errors, allow users to cleanly detach from the target
and quit.
Fixes#614
* proc: Next/Step should not panic if line info can not be found.
Fixes#683
* 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
Generate names of the concrete types stored inside interface variables
by fully parsing their runtime._type instead of simply using the str
field.
This allows delve to read the contents of an interface variable when
the program imports multiple packages that have the same name. It also
allows delve to correctly interpret some complex anonymous types.
Fixes#455
If the location specification matches the name of a function exactly
return that function as a match event if the expression matches other
functions as well.
Without this some functions, like math/rand.Intn are unmatchable.
* proc: changed windows backend to deal with simultaneous breakpoints
* bugfix: forgot to add windowsPrologue3 to the prologues list in e4c7df1
* Tolerate errors returned by Stacktrace in TestStacktraceGoroutine.
* bugfix: proc: propagate debug events we don't cause back to the target process
Fixes: #594
* proc: fixed TestStepConcurrentPtr
Implementation of nextInProgress was wrong.
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
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
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
* 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
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
