arch-arm: Fix TarmacParser handling of 64bit LD/ST

The TarmacParser was assuming 32 bit accesses only.
This was creating a mismatch when parsing a trace with 64 bit
accesses.

E.g.

In

clk IT (18) 002001f4 f8008441 O EL3h_s : STR      x1,[x2],#8
clk MW8 00201008:000000201008 00000000_40000401

Only the 32 MSBs were checked (00000000)

Change-Id: I51e803b53efe953edcd9378f6c9481c04932331e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21562
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>

src/arch/arm/tracers/tarmac_parser.cc

@@ -873,9 +873,7 @@ TarmacParserRecord::dump()
 {
     ostream &outs = Trace::output();
 
-    // By default TARMAC splits memory accesses into 4-byte chunks (see
-    // 'loadstore-display-width' option in TARMAC plugin)
-    uint32_t written_data = 0;
+    uint64_t written_data = 0;
     unsigned mem_flags = ArmISA::TLB::MustBeOne | 3 |
         ArmISA::TLB::AllowUnaligned;
 
@@ -1161,7 +1159,16 @@ TarmacParserRecord::advanceTrace()
             // Skip phys. address and _S/_NS suffix
             trace >> c >> buf;
         }
-        trace >> memRecord.data;
+        uint64_t data = 0;
+        trace >> data;
+        c = trace.peek();
+        if (c == '_') {
+            // 64-bit value with _ in the middle
+            uint64_t lsw = 0;
+            trace >> c >> lsw;
+            data = (data << 32) | lsw;
+        }
+        memRecord.data = data;
         trace.ignore(MaxLineLength, '\n');
         buf[0] = 0;
     } else {