Checkpointing is useful for saving long simulations. Checkpoint files are only valid for simulations that load the same object file that was used to produce the checkpoint. A few minimal consistency checks are performed to alert the user of a mistake.
The structure of the whole-program (after state allocation) is not retained in the checkpoint; rather, it is regenerated from the object file. Note: Only the state of variables (their values) and events is written to the checkpoint. Simulator modes, breakpoints, watchpoints, and dlopen-ed modules are not preserved in checkpoints, nor are they affected by loading checkpoints.
TODO: periodic checkpointing, via auto-save.
Saves the current simulator state to a checkpoint file ckpt that can be restored later. Overwrites ckpt if it already exists.
Restores the simulator state (variables and events) from a checkpoint file ckpt. Loading a checkpoint will not overwrite the current status of the auto-save file, the previous autosave command will keep effect. Loading a checkpoint, however, will close any open tracing streams.
Entire execution traces may be saved away for offline analysis. Again the structure of the whole-program (after state allocation) is not recorded in the trace; rather, it is assumed from the object file.
TODO: Section on trace file details and internals?
Record events to tracefile file. Overwrites file if it already exists. A trace stream is automatically closed when the initialize or reset commands are invoked. See the -r option for starting up the simulator with a newly opened trace stream.
Finish writing the currently opened trace file by flushing out the last epoch and concatenating the header with the stream body. Trace is automatically closed when the simulator exits.