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
  • #4263
Closed
Open
Issue created Apr 19, 2020 by Derek Bruening@derekbrueningContributor

Use new ARM atomic opcodes where available, for DR and even for app

These are ideas from @algr :

ARMv8.1 adds atomic add opcodes with release-acquire semantics: LDADDA, LDADDAL, LDADDL, and corresponding STADD*, etc. These are simpler to use and preferable to the exclusive monitor loops in DR's own code. DR would need to dynamically select whether these were available in the underlying processor.

Furthermore, we could potentially translate some exclusive monitor loops in the application to use these new atomic opcodes instead, avoiding the exclusive monitor instrumentation issue #1698.

Assignee
Assign to
Time tracking