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