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
  • #3798
Closed
Open
Issue created Aug 22, 2019 by Derek Bruening@derekbrueningContributor

Add interface for application register barriers inside the core

When the DR core performs certain "mangling" operations (application transformations required for core operation), it needs to read application register values. This can conflict with drreg and clients in general who may be storing app values in memory temporarily. This issue is asking for some kind of interface where the core can interact with drreg and clients to request a barrier where all values need to be in registers.

Today, for rseq (#2350 (closed)), such a barrier is assumed to be in place at the start and end of blocks. drreg obeys that today. In the future we may want to support longer-range optimizations and trace optimizations, however.

This issue also covers documenting these implicit barriers.

Assignee
Assign to
Time tracking