Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drmemtrace -trace_after_instrs introduces gap between first and second timestamps #6745

Open
abhinav92003 opened this issue Mar 29, 2024 · 1 comment · May be fixed by #6746
Open

drmemtrace -trace_after_instrs introduces gap between first and second timestamps #6745

abhinav92003 opened this issue Mar 29, 2024 · 1 comment · May be fixed by #6746
Assignees

Comments

@abhinav92003
Copy link
Contributor

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>

@abhinav92003 abhinav92003 self-assigned this Mar 29, 2024
abhinav92003 added a commit that referenced this issue Mar 29, 2024
Fixes a timestamp gap between the first and second timestamps in the trace
caused when -trace_after_instrs is used.

Fixes: #6745
@abhinav92003 abhinav92003 linked a pull request Mar 29, 2024 that will close this issue
@derekbruening
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants