Re: [DynInst_API:] Unable to instrument chromium


Date: Tue, 18 Nov 2014 09:42:31 -0800
From: Josh Stone <jistone@xxxxxxxxxx>
Subject: Re: [DynInst_API:] Unable to instrument chromium
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.
[← Prev in Thread] Current Thread [Next in Thread→]