Package ghidra.trace.model.memory

Interface TraceRegister

All Superinterfaces:
TraceObjectInterface
All Known Implementing Classes:
DBTraceObjectRegister
public interface TraceRegister extends TraceObjectInterface
A register

There are two conventions for presenting registers and their values. Both are highly recommended:

  1. In the TraceMemoryManager: If this convention is not implemented by the connector, then the trace database itself will try to convert the object-model tree presentation to it, because the only way to annotate data types and references in registers is to instantiate the appropriate register space. See the manager's documentation for how to set these up. NOTE: The TraceRegisterContainer for the relevant thread or frame must exist in this convention, even if the tree convention is not presented.
  2. In the TraceObjectManager: This convention is required when a register is not known to Ghidra's slaspec, which is certainly the case if the connector falls back to the DATA processor. It is easiest just to always present the tree. It provides some redundancy in case the memory-manager presentation gets broken, and it allows the user to choose a preferred presentation. In the tree convention, each register is presented with this interface. The name is taken from the object key, the length in bits is given in the attribute KEY_BITLENGTH, and the value is given in the attribute TraceObjectInterface.KEY_VALUE. Alternatively, connectors may present registers as primitive children of the container.

Some connectors may present registers in groups. To support this, there is an explicit TraceRegisterContainer. Ordinarily, the client would use the schema to detect a "container" of TraceRegister; however, that is not sufficient with groups. The root container (per thread or per frame) is marked as the TraceRegisterContainer. The connector may then organize the registers into groups, each group being a plain TraceObject, so long as each TraceRegister is a successor to the register container.