Summary

This PR makes gem5's Exec trace output less misleading for faulting instructions by appending a clear FAULTING marker when an instruction is known to have faulted (and ExecFaulting tracing is enabled).

This is especially helpful for O3CPU runs in syscall-emulation (SE) mode where a faulting memory operation may be re-fetched and re-executed after the fault handler (e.g., lazy stack growth) runs. In that situation, users can otherwise interpret two Exec lines for the same PC as a “duplicate execution” bug.

References: gem5 Issue #2902

• arch-riscv: O3CPU execute twice Store Doubleword instruction (sd) #2902

Motivation / Problem

Issue #2902 reports that a RISC-V O3CPU run shows the same sd instruction appearing twice in the Exec trace (with different FetchSeq values), which looks like gem5 executes the store twice.

In the reproducer attached to the issue, the first dynamic instance of the store faults due to SE-mode page-table handling / lazy stack growth (a GenericPageTableFault which triggers Process::fixupFault() to allocate a new stack page). The CPU then squashes younger instructions and re-fetches from the faulting PC; the store appears again as a new dynamic instruction instance.

Today, the Exec trace line for the faulting instance looks identical to a normal executed MemWrite, making the trace easy to misread.

What this PR changes

When ExecFaulting is enabled and the tracer record is marked as faulting, the Exec trace line now includes a trailing FAULTING tag.

This is deliberately minimal and formatting-only:

• No pipeline/memory behavior changes.
• No changes to fault handling.
• Only adds clarity to an existing debug trace.

Before / After (example from Issue #2902)

Before

The trace excerpt in Issue #2902 looks like two identical stores:

2643000: system.cpu: T0 : 0x11a4e @_Z11modify_datai+2170 : sd a0, -2016(a2) : MemWrite : D=0x00000000000166d2 A=0x7fffffffffffc6f0 FetchSeq=653
2849000: system.cpu: T0 : 0x11a4e @_Z11modify_datai+2170 : sd a0, -2016(a2) : MemWrite : D=0x00000000000166d2 A=0x7fffffffffffc6f0 FetchSeq=684

After

With this change, the faulting dynamic instance is clearly labeled:

2643000: system.cpu: T0 : 0x11a4e @_Z11modify_datai+2170 : sd a0, -2016(a2) : MemWrite : D=0x00000000000166d2 A=0x7fffffffffffc6f0 FetchSeq=653  FAULTING
2849000: system.cpu: T0 : 0x11a4e @_Z11modify_datai+2170 : sd a0, -2016(a2) : MemWrite : D=0x00000000000166d2 A=0x7fffffffffffc6f0 FetchSeq=684

This makes it explicit that the first appearance is not a successful architectural store retirement, but a faulting instance which will be handled and then retried.

Notes

• Exec already includes the ExecFaulting flag (via the CompoundFlag('Exec', ...)), so users enabling --debug-flags=Exec automatically benefit from the clearer output.
• The marker is intentionally concise (FAULTING) to minimize impact on existing trace parsing.