FDEs previously were loaded into a red/black tree and searched. This is
significantly more expensive than a binary search over a slice. Not sure
what I was thinking using a red/black tree - this binary search
implementation is significantly more efficient.
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.
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.
Now that I'm using the step strategy, I put in an optimization where if
stepping into another function, simply find the return address, put a
breakpoint there, and then continue.
I decided to vendor all debug/dwarf and debug/elf files so that the
project can be go get-table. All changes that I am waiting to land in Go
1.4 are now captured in /vendor/debug/*.
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.
