A Running Program Becomes Another Kind of Evidence

Ghidra's Debugger extends the program model from saved code into observed machine state. This chapter focuses on the path from a local or remote native debugger through Trace RMI into a Ghidra trace, and then from captured state into p-code emulation. The practical judgment is to keep three things separate: what the live target is doing, what the trace recorded, and what an emulator predicted from a selected state and schedule.

From a native target to a trace

A native debugger has direct access to platform APIs, processes, threads, registers, memory, and target events. Ghidra's UI should not have to host every one of those APIs in the same process. The Developer's Guide describes a trace-modeling schema for recording machine state and markup over time, together with Trace RMI as a protocol between Ghidra and debugger back ends. The design keeps native API access outside the Ghidra UI JVM, helping contain crashes and providing a bridge between Java inside Ghidra and Python-based back ends.

The trace is the boundary object. A back end connects to a target, observes selected state, and populates a trace with information such as machine state, disassembly and data-type markup, threads, loaded modules, and breakpoints. The trace can be stored using the same database framework as Programs and may be shared through a server. It is not automatically a complete recording of everything the target knows. The back end decides what to observe and when to record it.

That ownership decision affects the meaning of a later question. If a trace records registers at a stop but not a region of memory that the target read earlier, the analyst may be able to explain the current instruction but not reconstruct the earlier data dependency. If a module was loaded without the corresponding static program, the trace may show dynamic addresses without a reliable static mapping. If a breakpoint event was recorded without all thread state, the event can establish that execution stopped while leaving the reason for a later value unresolved. A trace is valuable because it preserves selected state over time, not because it eliminates selection.

The same distinction helps when traces are shared. A colleague can inspect a recorded snapshot and its markup without controlling the original target, but they inherit the recording choices and mapping assumptions made by the back end. Sharing a trace therefore extends the evidence model; it does not turn a partial observation into a complete replay of the process.

stateDiagram-v2 [*] --> Target Target --> TraceRMI: Observe through back end TraceRMI --> TraceSnapshot: Record selected state TraceSnapshot --> EmulatorSchedule: Start emulation or navigate time EmulatorSchedule --> PatchedState: Apply patch or model PatchedState --> EmulatorSchedule: Step again TraceSnapshot --> MissingContext: State or mapping absent EmulatorSchedule --> MissingContext: Userop or environment failure MissingContext --> TraceSnapshot: Capture or model missing context TraceSnapshot --> [*]

The target and the trace are related but not interchangeable. A target can continue running while the trace contains only the snapshots and observations the back end has synchronized. A static symbol can be translated into a dynamic address when the module mapping is correct, and reading memory from the target can capture that region into the trace. If the target is remote, the file path that names a module on the target may not exist on the Ghidra host.