On 11/18/2014 08:40 AM, bill wrote: > ...well, that's a problem. Really, that's two problems. I'll see what I > can do about these, but it may take me a bit--I'm at SC this week. > > We're trying to parse the entire process at creation time in order to > install pre-fork instrumentation. The attentive Dyninst developer will > note two problems with that sentence: > > 1) "entire process" > 2) "pre-fork instrumentation" > > We should only be looking for fork in the appropriate places (libc, or > the executable itself if we're in a statically linked environment) > rather than the whole process,
It's possible in theory for a fork to arise elsewhere, but given that syscall-linux.C is only looking for "__libc_fork", reducing the search is probably fine. > and we should be able to get pre-fork out > of ptrace callbacks and not need instrumentation for it (I'm sure Matt > and/or Josh will correct me if I'm wrong there). PTRACE_EVENT_FORK is when fork is about to return, and I believe we do use it for post-fork callbacks. You could use PTRACE_SYSCALL to get the pre-fork, but you'd have to stop all syscalls all the time. AFAICS, the only use of this instrumentation trickles down to BPatch::registerForkingProcess() to call the user's preForkCallback. So could we be lazy and wait until that callback is actually requested? In fact that's already noted in PCProcess::bootstrapProcess(): > // TODO > // pre-fork and pre-exit should depend on whether a callback is defined > // > // This will require checking whether BPatch holds a defined callback and also > // adding a way for BPatch enable this instrumentation in all processes when > // a callback is registered That still leaves a constant breakpoint for pre-exec, whose only job is to make proc->isExecing() work. I'm not sure if that one could be determined some other way. That seems to exist just to avoid removing instrumentation from the process that went away, since it's now a "new" process with different memory. _______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
