-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat(forge): add calldata and returndata views to debugger #7110
feat(forge): add calldata and returndata views to debugger #7110
Conversation
…r scroll down calculations
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.
Nice, I like this, just a nit
crates/debugger/src/tui/draw.rs
Outdated
opcode::CREATE | opcode::CREATE2 => (2, 3, 0, 0), | ||
opcode::CALL | opcode::CALLCODE => (4, 5, 0, 0), | ||
opcode::DELEGATECALL | opcode::STATICCALL => (3, 4, 0, 0), | ||
) -> (Option<BufferKind>, Option<usize>, Option<usize>, Option<usize>, Option<usize>) { |
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.
Clippy is complaining about this, which is fair. You can extract it into a struct and return one Option<_>
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.
sweet!
pending @DaniPopes
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.
awesome work. Pending clippy & @DaniPopes
…oundry-rs#7110)" This reverts commit e10b039.
Motivation
It's often useful to see what data is actually in calldata/returndata, as well as see which regions are being operated on.
Closes #5492.
Solution
DebugStep
active_buffer
toDebuggerContext
get_memory_access
->get_buffer_accesses
; note which buffer is being read from, if any; simplify return typedraw_memory
->draw_buffer
; compare read/writes to current active bufferb
("buffer") operator to debugger to cycle Memory -> Calldata -> Returndata buffers in the "buffer" panel viewb
to help string; update references of "memory" to "buffer"Unsure of where debugger tests live (if anywhere), but draw logic seems to handle edge cases well; I'd be most concerned about potential performance issues or highlighting regions in the wrong buffer.
Screenshots:
Calldata access:




Memory overwrite from calldatacopy:
Returndata access:
Memory overwrite from returndatacopy: