-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Interpreter Debug Hooks #73
Conversation
Codecov Report
@@ Coverage Diff @@
## master #73 +/- ##
==========================================
- Coverage 85.89% 84.05% -1.84%
==========================================
Files 30 34 +4
Lines 3034 3293 +259
==========================================
+ Hits 2606 2768 +162
- Misses 285 380 +95
- Partials 143 145 +2
Continue to review full report at Codecov.
|
bscript/interpreter/debug.go
Outdated
|
||
// ThreadState a snapshot of a threads state during execution. | ||
type ThreadState struct { | ||
DStack [][]byte |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's DStack? is this the main stack and AStack is the alt stack?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah dstack is the main data stack and astack is the alt stack, do you think these should be named better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm used to main stack and alt stack but it's fine
Op opcode | ||
// ParsedOpcode is a parsed opcode. | ||
type ParsedOpcode struct { | ||
op opcode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any specific reason why you made this private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes because the data type is both private, and is used as an interally to map opcodes with their byte value, their name, and their function. I worried exposing it in a non-readonly way would allow users to mess with the state of the interpreter mid execution, either via value reassignment or calling opcode functions.
|
||
// WithDebugger enable execution debugging with the provided configured debugger. | ||
// It is important to note that when this setting is applied, it enables thread | ||
// state cloning, at every configured debug step. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by "thread state cloning"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each attachment point calls thead.state()
, which takes a snapshot of the current threads state and clones it into a ThreadState
struct. This is done to ensure that if the user modifies the state in these debug functions, it doesn't impact the state of the interpreter.
I thought it was necessary to call this out because, if it was happening both before and after each opcode execution, it could end up being an expensive enough operation.
This is just a word of caution for those looking to enable these features on production performance critical systems.
good stuff mate, it looks pretty good froma high level.. what would be the easiest way for me to test it out? also have you seen this debugger (it's really out of date and has some issues but serves as a nice PoC)? we've done some similar shit internally - ask me about it next time and i'll tell you more about it |
Placing work-in-progress label back on this as I've had a couple more ideas on where this could go. @jadwahab right now you'd just need to write some code and run it, but I'll get working on an |
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
Currently there is no observability into the execution of the interpreter, be it during or after.
To try to address this, I've added the notion of a
Debugger
which by default is no-op, but can be configured to expose a series of hooks throughout athread
's runtime. Attaching onto these hooks provides a copy of the executing thread's runtime state, at the point of the function call.Also, as a direct result of this,
ParsedOpcode
is likely going to see more usage in an exported context, so I've cleaned up that struct a bit to make it more user friendly.Usage example: