Core Simulation Support

The drcachesim trace format includes information intended for use by core simulators as well as pure cache simulators. For traces that are not filtered by an online first-level cache, each data reference is preceded by the instruction fetch entry for the instruction that issued the data request. Additionally, on x86, string loop instructions involve a single insruction fetch followed by a loop of loads and/or stores. A drcachesim trace includes a special "no-fetch" instruction entry per iteration so that core simulators have the instruction information to go along with each load and store, while cache simulators can ignore these "no-fetch" entries and avoid incorrectly inflating instruction fetch statistics.

Offline traces guarantee that a branch target instruction entry in a trace must immediately follow the branch instruction with no intervening thread switch. This allows a core simulator to identify the target of a branch by looking at the subsequent trace entry. However, this guarantee does not hold when a kernel event such as a signal is delivered immediately after a branch.

Traces include scheduling markers providing the timestamp and hardware thread identifier on each thread transition, allowing a simulator to more closely match the actual hardware if so desired.

Traces also include markers indicating disruptions in user mode control flow such as signal handler entry and exit.

Filtered traces (filtered via -L0_filter) include the dynamic (pre-filtered) per-thread instruction count in a TRACE_MARKER_TYPE_INSTRUCTION_COUNT marker at thread exit.

A final feature that aids core simulators is the pair of interfaces module_mapper_t::get_loaded_modules() and module_mapper_t::find_mapped_trace_address(), which facilitate reading the raw bytes for each instruction in order to obtain the opcode and full operand information.