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.
packagename.SomeFunction should match
github.com/someuser/packagename.SomeFunction since the former is
the familiar syntax.
To disambiguate between io.SomeFunction and
github.com/someuser/somepackage/io.SomeFunction specify one extra
slash at the start of the location specifier: /io.SomeFunction.
Fixes Issue #296
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
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)
