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)
Use proc.(*Process).FindGoroutine in proc.(*Process).SwitchGoroutine and
debugger.(*Debugger).Stacktrace. That method did not exist when those
were originally written.
Without arguments, `list` displays source around the current context. A
linespec argument can be taken to display source around that location.
Fixes#58
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
the entry point of a function is the beginning of the prologue, which can be run multiple times for each invocation of a function if the stack needs to be expanded or the scheduler needs to be run.
Instead of maintaining two separate client / server implementations,
maintain only the more lightweight JSON-RPC service. The reasoning
behind the merging of the original HTTP service was ease of tooling, in
other words low barrier of entry for external clients (editor
integrations, etc...).
I believe the JSON-RPC solution still satisfies that constraint while
have the advantage of being a more lightweight solution. HTTP, while
highly supported in most modern languages, carries with it too many
features we would never take advantage of. The RPC architecture seems
a more natural approach.
The infrastructure set up during the initial HTTP service implementation
was leveraged in the JSON-RPC implementation, so if any of those
original authors are reading this commit message: thank you for that
work, it was not in vain even if though the original HTTP service is not
being removed.
Previously either the terminal client or the debugger service would
either lock main goroutine to a thread or provide a locked goroutine to
run _all_ DebuggedProcess functions in. This is unnecessary because only
ptrace functions need to be run from the same thread that originated the
PT_ATTACH request.
Here we use a specific thread-locked goroutine to service any ptrace
request. That goroutine is also responsible for the initial spawning /
attaching of the process, since it must be responsible for the PT_ATTACH
request.
Add a test support package which allows shared test functionality
for both the unit and integration tests.
Tests importing the proctl/test package will gain access to a special
test entrypoint which precompiles fixtures and makes them available
to tests.
Refactor to introduce client/server separation, including a typed
client API and a HTTP REST server implementation.
Refactor the terminal to be an API consumer.
