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
  • #1834
Closed
Open
Issue created Dec 10, 2015 by Derek Bruening@derekbrueningContributor

better support for clients de-referencing far, PC-relative, or stolen-reg-base app memory values: have DR mangle them

Split from #1823 (closed)

This seems like a more general problem than just an issue with dr_insert_mbr_instrumentation(). While often inserted code that de-references app memory is app code, this is not always the case, and we want to support tool code doing so. Similarly to the stolen register on ARM, we should at least document that the burden falls on clients to detect and handle far refs on Linux rather than blindly copying opnds. We should also add convenience routines if it is too awkward to work around this using regular API routines.

A similar problem exists with PC-relative memory references: if a tool blindly copies the operand, is DR supposed to try and mangle it, potentially spilling a register and maybe messing up the tool's instrumentation assumptions?

One proposal would be a drutil_insert_get_mem_value() routine in an extension that handles the corner cases.

Assignee
Assign to
Time tracking