Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #5141
Closed
Open
Issue created Oct 04, 2021 by Derek Bruening@derekbrueningContributor

drmemtrace offline traces violate invariant with adjacent branches split by buffer boundaries

The drmemtrace offline traces support core simulation where branch targets are needed. They provide an invariant that a thread switch won't occur between a branch and its target, so the simulator can have the target at the time it sees the branch. (Even if we added an explicit branch target entry to the trace we would probably still implement it this way in post-processing, waiting for the next block, rather than having online instrumentation deduce the target before the branch occurs.)

However, upon strengthening the invariant_checker tool's check for this invariant to look for potential thread switches at thread buffer boundaries (to make the check parallelizable), we see violations where a thread switch could have occurred:

T519347   0x00007efcf20023c2  66 85 c9             data16 test   %cx, %cx
T519347   0x00007efcf20023c5  74 91                jz     $0x00007efcf2002358
T519347   0x00007efcf20023c7  66 83 f9 f1          data16 cmp    %cx, $0xf1
T519347   0x00007efcf20023cb  74 d3                jz     $0x00007efcf20023a0
T519347 <marker: timestamp 13277591301494781>
T519347 <marker: tid 519347 on core 0>
T519347   0x00007efcf20023cd  eb 90                jmp    $0x00007efcf200235f
T519347   0x00007efcf200235f  44 0f b6 52 04       movzx  0x04(%rdx), %r10d
T519347     read  1 byte(s) @ 0x7efcf1ed3b2c
T519347   0x00007efcf2002364  41 83 e2 0f          and    $0x0f, %r10d

Quoting from PR #5139:

I think the consecutive branches breaks the raw2trace delayed branch feature and we've just never had that coincide with a thread switch before:

[drmemtrace]: Appending 2 instrs in bb 0x7fd14918d3c7 in mod 19 +0x1373c7 = /lib/x86_64-linux-gnu/libc-2.31.so
  0x00007efcf20023c7 data16 cmp    %cx $0xfff1
  0x00007efcf20023cb jz     $0x00007efcf20023a0
[drmemtrace]: Appending delayed branch for thread 2
[drmemtrace]: Appending 1 instrs in bb 0x7fd14918d3cd in mod 19 +0x1373cd = /lib/x86_64-linux-gnu/libc-2.31.so
  0x00007efcf20023cd jmp    $0x00007efcf200235f
[drmemtrace]: Thread 519347 timestamp 0x002f2be620ff97fd
[drmemtrace]: Appended marker type 3 value 0x0
[drmemtrace]: Appending delayed branch for thread 2
[drmemtrace]: Appending 4 instrs in bb 0x7fd14918d35f in mod 19 +0x13735f = /lib/x86_64-linux-gnu/libc-2.31.so
Assignee
Assign to
Time tracking