DynamoRIO / DynamoRIO/dynamorio

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

Open
#2,157 3 comments 0 reactions 1 assignee Claimed by @Carrotman42 View on GitHub
Type-Feature
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

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, 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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.