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.

Sign up for GitHub

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

Jump to bottom

Record the signal number in drmemtrace traces #6884

Closed
derekbruening opened this issue Jul 15, 2024 · 0 comments · Fixed by #6885
Closed

Record the signal number in drmemtrace traces #6884

derekbruening opened this issue Jul 15, 2024 · 0 comments · Fixed by #6885
Assignees
@derekbruening
Labels
Component-DrMemtrace Type-Feature

Comments

@derekbruening
Copy link
Contributor

We've had a few cases of postprocessing raw drmemtrace traces into final traces where we wanted to know whether a signal was synchronous or asynchronous. Some analyses of traces want to know what type of signal it is. The TRACE_MARKER_TYPE_KERNEL_EVENT's value is already occupied, so we'd add a new marker type.
@derekbruening derekbruening self-assigned this Jul 15, 2024
derekbruening added a commit that referenced this issue Jul 16, 2024
@derekbruening
i#6884: Add drmemtrace signal number marker
d32d876 
Adds a new drmemtrace marker holding the signal number which is
emitted after the kernel event marker.  It is not emitted at the
signal return point; only at the transfer to the handler.

Does not add a feature bit or increase the version as this marker is
considered optional and so no mechanism is provided for users to be
guaranteed that it is present.

Adds view tool support.

Adds a test that the marker is emitted in the burst_gencode test.
Output from the test's trace:
```
          52          32:     1616564 ifetch       2 byte(s) @ 0x00007f615935d023 0f 0b                ud2
          53          32:     1616564 <marker: kernel xfer from 0x7f615935d023 to handler>
          54          32:     1616564 <marker: signal #4>
          55          32:     1616564 <marker: timestamp 13365562571171519>
          56          32:     1616564 <marker: tid 1616564 on core 9>
          57          33:     1616564 ifetch       1 byte(s) @ 0x00005641b091170b 55                   push   %rbp
```

Fixes #6884
@derekbruening derekbruening mentioned this issue Jul 16, 2024
Merged
derekbruening added a commit that referenced this issue Jul 16, 2024
@derekbruening
i#6884: Add drmemtrace signal number marker (#6885)
1211505 
Adds a new drmemtrace marker holding the signal number which is emitted
after the kernel event marker. It is not emitted at the signal return
point; only at the transfer to the handler.

Does not add a feature bit or increase the version as this marker is
considered optional and so no mechanism is provided for users to be
guaranteed that it is present.

Adds view tool support.

Adds a test that the marker is emitted in the burst_gencode test. Output
from the test's trace:
```
          52          32:     1616564 ifetch       2 byte(s) @ 0x00007f615935d023 0f 0b                ud2
          53          32:     1616564 <marker: kernel xfer from 0x7f615935d023 to handler>
          54          32:     1616564 <marker: signal #4>
          55          32:     1616564 <marker: timestamp 13365562571171519>
          56          32:     1616564 <marker: tid 1616564 on core 9>
          57          33:     1616564 ifetch       1 byte(s) @ 0x00005641b091170b 55                   push   %rbp
```

Fixes #6884
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@derekbruening derekbruening

Labels
Component-DrMemtrace Type-Feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

i#6884: Add drmemtrace signal number marker DynamoRIO/dynamorio
1 participant
@derekbruening