<< Click to Display Table of Contents >> Navigation:  ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 21 – Debugging, Tracing, and Determinism > 21.9 SMP Debugging Considerations

SMP debugging introduces challenges that do not exist in single-CPU configurations. Each CPU has an independent trace stream. There is no implicit global serialization for debugging — global ordering must be reconstructed from per-CPU timestamps. Cross-CPU events (IPIs, barrier synchronization, TLB shootdowns, reservation invalidations) are correlated explicitly through CPU ID tagging in all log entries.

 

Recommended SMP debugging practices:

 

Always identify CPU ID in logs — every DEBUG_LOG in CBox, FaultDispatcher, ReservationManager, and barrier coordination includes the CPU identifier. Track reservation creation and invalidation — ReservationManager logs setReservation() and breakReservationsOnCacheLine() with cache line addresses and CPU IDs. Log barrier stall and release events — CBox logs barrier kind, stall entry, and release; MemoryBarrierCoordinator logs initiation, acknowledgment count, and timeout. Trace IPIs and acknowledgments — IPIManager tracks totalCount per CPU; IPI send/receive is logged with command type and target CPU. Verify TLB invalidation paths — handleTLBShootdownIPI() logs the invalidation command, VA, and ASN on receipt.

 

SMP ordering differences between runs are intentional when deterministic scheduling mode is disabled. When deterministic mode is enabled, SMP execution is fully reproducible. MMIO bugs are ordering bugs until proven otherwise — always trace device MMIO reads/writes with CPU ID and correlate with barrier events.

 

See Also: Chapter 9 - SMP Architecture (SMP execution model); 11.9 Debugging and Observability Invariants  (normative debugging requirements).