This plugin controls the modification of machine state. It provides a multi-state action in the main toolbar for controlling the editing mode of each trace and associated target. It is backed by a corresponding service plugin which manages the editing modes and dispatches machine-state edits accordingly. Scripts can also use the service to perform machine-state edits that behave consistently with the rest of the UI.
The plugin provides a single action:
This action is available whenever a trace is active. It changes the machine-state editing mode for the active trace and, if applicable, its associated target. The possible modes are:
Write Target is the default mode, because in most cases, this is the desired behavior. When the target dies, Write Target essentially means Read Only. For the most part, modifying the recording itself is discouraged. There are few reasons, perhaps including 1) Hand-generating an experimental trace; 2) Generating a trace from a script, e.g., importing an event log, recording an emulated target; 3) Patching in state missed by the original recording. More often than not, when experimenting with the emulator, the mode should be Write Emulator. Using Write Trace with the emulator will almost certainly result in issues with cache staleness.
Some background and an example: To display emulated machine state, the emulator executes a specified schedule and writes the resulting state into the trace's scratch space, keyed by the schedule. Suppose you emulate a step forward but then realize that some state was incorrect, or you just want to try the same step with an alternative initial state. If you step back then edit the trace and then repeat the step forward, the UI will simply recall the cached snapshot, rendering the state change ineffective. Instead, use Write Emulator to edit the state and then step forward. Because the patch is encoded in the emulation schedule, the UI will not recall the stale snapshot. Instead the emulator will execute the new schedule and generate a new scratch snapshot. Furthermore, the original trace recording remains in tact, while the modified state is stored in scratch space with the schedule explaining where it came from. Still better, the first scratch snapshot (for the step taken without first modifying the state) also remains in tact, and the two can be compared.
To prevent edits to a live target, use the Read-Only mode. This will prevent most accidental edits. This is only effective against edits from the UI, and only when all plugins and scripts use the state editing service. This cannot prevent a component from accessing Ghidra's Target API to modify a target. Nor can it prevent edits via the connected debugger's command-line interpreter. The following components all use the service: Dynamic Listing, Memory (Dynamic Bytes), Registers, and Watches.