Need a truly read-only mode of proccontrol

[cuviper]

Via rhbz 1366574, it would be nice to be able to use proccontrol in a purely observational mode, without modifying the mutatee at all.

We avoided one breakpoint already by adding LibraryTracking::setDefaultTrackLibraries(false), which is undocumented (#151). Now we find that initThreadDB() places additional breakpoints, and there don't seem to be any flags to avoid it.

I'm surprised that these TD_CREATE and TD_DESTROY events are even needed -- don't ptrace events already cover this?

But even if we solve that particular case, it would be nice to have some stronger guarantees in general. Is it possible to have a truly read-only mode of proccontrol? If so, perhaps this could be a flag somewhere when creating/attaching the mutatee, so this intent is clear.

[wrwilliams]

I think this is a sane thing to want. The breakpoints are to capture the threaddb events which map to the user-level thread create/destroy as opposed to the LWP create/destroy. They may be redundant most of the time, and certainly if one is aiming for a purely observational mode, configuring proccontrol without threaddb would be a workaround for the moment.

We need to think about what a true read-only interface will and won't guarantee; do you have initial thoughts or requests from further downstream on what the necessary operations in read-only mode are?

[wrwilliams]

Secondary questions @cuviper: is the downstream goal to be robust up to and including SIGKILL on the tool, or is proper detach and cleanup via atexit or moral equivalent okay? Are we allowed to still potentially cause mutatee failure in cases where we're delivering a signal to the mutatee when we're killed? In short, what are the practical forms of abnormal tool termination that downstream is concerned with, and what forms are allowed to adversely affect the mutatee (on the grounds of rarity, inability to mitigate, or whatever else)?

This will not be an easy thing to do in a platform-independent way (there is not a well-defined set of features across platforms that definitionally is read-only on the mutatee).

[cuviper]

I believe that would be ideal, yes -- if the tool dies for any reason, the mutatee should just carry on as if it were never there. With that kind of promise, one could feel safe using the tool on any process on the system. I'll see if @fweimer would like to elaborate his requirements directly.

RE platform independence -- of course we care mostly about Linux behavior. This could mean that Dyninst simply needs to document these platform differences, if some things are just read-only under specific circumstances.

[mplegendre]

You can disable the thread_db code via the ThreadTracking class, which similar to the LibraryTracking class. In both cases you use the setDefaultXXX() functions to turn on/off tracking in all future processes, or the setXXXX() functions to turn it on/off in selected processes. I suspect you want the setDefaultXXXX() versions for this use case. Currently we use these interfaces on BG/Q to get better performance when attaching to large numbers of processes.

Off the top of my head, disabling Thread and Library tracking would disable all of ProcControlAPI's persistent internal breakpoints on Linux. Both system-call completion and PPC single-stepping may use temporary breakpoints, and I don't think those can be currently disabled. We may want a targeted interface towards a "read-only" mode to disable those.

[cuviper]

Huh, how did I miss that? It's right at the top of initThreadDB, a short-circuit on track_threads which was initialized from ThreadTracking::getDefaultTrackThreads(). Although FWIW I can't find any caller of ThreadTracking::getTrackThreads(). Anyway, I'll give that a shot.

Temporary breakpoints are probably OK, if they're infrequent and short-lived. Especially so if the user has control to decide whether to use features that need this, which again requires some documentation.

[fweimer]

I wrote the original feature request.

I'm working on some experimental analysis tool for live processes, with the eventual goal to hand this tool to customers to run in production. It would be helpful if I could confidently say that the impact of the tool on the target process would be, in the worst case, similar to running strace -p on the target process. What I have seen during development is that when my tool exits unexpectedly, brackpoints in the target process persist, causing it to crash eventually.

Arguably, this is a limitation of Linux support for debuggers, but I have to work with what's currently shipping.