drmemtrace -trace_after_instrs introduces gap between first and second timestamps

[abhinav92003]

When drmemtrace tracing is done with -trace_after_instrs enabled, the timestamp in the trace buffer at thread-init is set to the then timestamp, but trace entries start pouring in only after the specified count of instrs have passed. This introduces a gap in the first and second timestamp in the trace, which is directly proportional to the requested -trace_after_instrs value.

For a simple_app trace collected using:

$ ./bin64/drrun -t drcachesim -offline -trace_after_instrs 100000 -- suite/tests/bin/simple_app

grepping for timestamps in the view tool output shows the diff.

$ grep timestamp /tmp/view.txt 
           6           0:     1922821 <marker: timestamp 13356213906110890>
       12485        9005:     1922821 <marker: timestamp 13356213907576928> <--- much after the first timestamp
       12487        9005:     1922821 <marker: timestamp 13356213907577279>
       15494       11278:     1922821 <marker: timestamp 13356213907766531>
       15497       11278:     1922821 <marker: timestamp 13356213907766846>
       21119       15375:     1922821 <marker: timestamp 13356213907800740>

[derekbruening]

Sounds like the timestamp solutions involving freezing or using restart timestamps for windows #6104 just need to include this delayed-trace case. Also xref the original frozen timestamps in #2039 and #5021.