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.
