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
Instead of the `step` command single stepping every thread, instead only
step the "current" thread. This fixes a few issues surrounding single
stepping, and simplifies the logic. The original concerns around only
stepping a single thread (with regard to coordination) are invalid and
generally non-issues.
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).
resume loops in continueOnce moved to a OS specific resume function,
this makes the problem easier to deal with and seems to be more
appropriate to a windows port given what transpired from discussion
of Pull Request #276
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.
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.
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
Three locations are returned for goroutines: its current location,
its current location excluding unexported runtime functions and
the location of its go instruction.
The command 'goroutines' takes a new parameter to select which
location to print (defaulting to current location w/o runtime)
Instead of using PTRACE_DETACH to inject SIGINT into the tracee use
sys.Kill directly: PTRACE_DETACH is allowed to ignore its signal
argument if the tracee isn't in signal-delivery-stop status.
Only use software breakpoints for now. The reasoning is because it
complicates the code without justification, and is only supported on
Linux. Eventually, once watchpoints are properly implemented we will
revive some of this code. Also, if it is ever necessary to actually set
a hw breakpoint we can revive that code as well.
All future versions of this code will include support for OSX before
being merged back in.
Use proc.(*Process).FindGoroutine in proc.(*Process).SwitchGoroutine and
debugger.(*Debugger).Stacktrace. That method did not exist when those
were originally written.
Some of the goroutines stored in runtime.allg are in the dead state and
should not be displayed. The state is determined by the 'g.atomicstatus'
member.
The GoroutineInfo method can be slow if there are many goroutines. This
patch caches the results during a halt so they are not needlessly
recomputed.
Fixes#234
`next` would hang in highly parallel programs, causing test flickers and
unexpected behavior. This patch fixes it by examining all stopped
threads whenever Delve gets a notification, instead of just the thread
that caused the stop.
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.
