You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should have a method to take a memory snapshot when the simulator is stopped at a breakpoint. This would let us have a collection of named memory snapshots that we could use to drive other symbolic execution tasks.
As an example workflow:
The user could being symbolic execution at main and run up to a breakpoint
They could then capture (and name) that memory state
Next, they can select a new function to begin execution with the saved memory state
This may not correspond to a real program execution, but it could be a very useful mechanism for asking targeted questions. This would be much more tractable as a method for populating memory states than handling it manually. Instead of starting from main, a user could also set up various custom entry points to construct memory states with desired properties, entirely using the host language.
Since Crucible data structures are all immutable, we don't need to worry about captured memory states becoming invalidated.
Note: there are some design questions here. We probably want to capture all of the Crucible globals, but is that enough for all backends? It would work for LLVM, but we need to look at the implications for go/java/rust.
The text was updated successfully, but these errors were encountered:
We should have a method to take a memory snapshot when the simulator is stopped at a breakpoint. This would let us have a collection of named memory snapshots that we could use to drive other symbolic execution tasks.
As an example workflow:
main
and run up to a breakpointThis may not correspond to a real program execution, but it could be a very useful mechanism for asking targeted questions. This would be much more tractable as a method for populating memory states than handling it manually. Instead of starting from
main
, a user could also set up various custom entry points to construct memory states with desired properties, entirely using the host language.Since Crucible data structures are all immutable, we don't need to worry about captured memory states becoming invalidated.
Note: there are some design questions here. We probably want to capture all of the Crucible globals, but is that enough for all backends? It would work for LLVM, but we need to look at the implications for go/java/rust.
The text was updated successfully, but these errors were encountered: