feat: track atomic memory access size#116
Conversation
ggeier
left a comment
ggeier
left a comment
There was a problem hiding this comment.
please check the value placeholders comment, besides that, great addition!
db7
left a comment
db7
left a comment
There was a problem hiding this comment.
LGTM, but the pipeline is failing. Why is that?
The benchmark workflow currently fails due to runner flakyness. #117 is should improve this, so we can merge it first. Then the pipeline should be green after rebasing |
|
The |
No idea. @ggeier |
|
I'd be ok with it. I can't override the check though. |
I’d remove that benchmark from the cicd rather than changing rules permanently. |
I thought maybe there’s a way for you to override it just once. The baseline would be lower afterwards, so I think it would not be a permanent problem. |
|
Ok, let’s do that. Just fix the merge conflict first. |
Introduces a new `coldtrace_atomic_access_entry` struct to record the exact byte size of atomic reads and writes in the binary trace files. - Extends atomic read/write trace entries from 16 to 24 bytes to include `size`. - Modifies TSan subscriber macros in `subs_tsan.c` to extract and serialize the size parameter. - Updates the `trace_dump.py` tool to correctly unpack the new 24-byte format and print the access size. Signed-off-by: mariaxarisi <maria.charisi@huawei.com>
Signed-off-by: mariaxarisi <maria.charisi@huawei.com>
|
Sorry, I didn’t realize the merge was blocked by a merge conflict 🫣. This UI is a bit confusing for me in that regard. Hope I’ll remember next time. |
3 participants
This PR introduces the ability to trace the memory access size for atomic operations.
What Changed:
coldtrace_atomic_access_entrystructure to correctly save the size data.trace_aread_awrite_size) to verify that atomic sizes are captured correctly.Related Issue: