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
  • #2157
Closed
Open
Issue created Jan 27, 2017 by Derek Bruening@derekbrueningContributor

support re-attach after full detach with the same DR library instance

Split from #95

For something like a ptrace-based external attach with an injected DR library, the solution here would be to remove the library completely on detach, leaving no extra work for a re-attach. This issue covers instead a re-attach for a DR library that we cannot remove, as it is either statically linked with the app or was not loaded by us as part of the attach but rather by the system loader up front.

Xref discussion on needing to re-attach after a full detach for start/stop when stop always does a full detach: https://github.com/DynamoRIO/dynamorio/issues/95#issuecomment-64834854

It's worth repeating the main paragraph there:

Supporting re-takeover when stopping is tied to full cleanup is problematic as it requires that DR fully zero all static and global variables. There are many cases of static variables scattered around, such as inside DO_ONCE, in the initializers for Extensions (drmgr, etc.), in memoized functions, etc. We'd have to make all those non-global-scope static vars exposed to get access to them, or try to zero out the whole .data and .bss (which by itself is not enough as there's a lot of non-zero-init stuff in .data). This has performance impliciations for chains of short-lived processes. We also have to deal with subtle things like #1271 (closed), where we threw out the .1config file under the assumption that we wouldn't re-read the options later. Plus, even if we make DR work in this model, third-party Extensions are unlikely to follow this: we would have to noisily demand a different programming model than is usually assumed.

Despite all of those problems, in the past we have gotten such a re-attach to work for simple cases, and even if the solution is fragile and "hacky" and does not cover all corner cases it may still be worth best-effort support as it removes a severe limitation of useful usage scenarios such as bursty traces.

Assignee
Assign to
Time tracking