Re: [DynInst_API:] Unable to instrument chromium

[bill <bill@xxxxxxxxxxx>]

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

On 2014-11-17 08:52, Adrian M Negreanu wrote:
> On Mon, Nov 17, 2014 at 3:13 PM, Adrian M Negreanu <groleo@xxxxxxxxx>
> wrote:
>
> > On Sat, Nov 15, 2014 at 12:03 AM, Bill Williams <bill@xxxxxxxxxxx>
> > wrote:
> >
> > > Two for correctness, and three for speed.
> > >
> > > Correctness:
> > > * saveFPRs is no longer a significant speed win, and disabling it
> > > can be a correctness loss when inserting calls to a wide variety
> > > of common libc functions--the XMM registers are used in all manner
> > > of unusual places.
> > I've removed the "saveFPR(false)" line.
> >
> > Â
> >
> > > * Inserting a call to printf where the argument totals don't match
> > > the format string is going to cause issues (possibly including an
> > > unbalanced stack and arbitrarily broken control flow).
> > >
> > > Speed:
> > > * Dyninst, like most programs that make heavy use of STL,
> > > performs remarkably badly at -O0. Make sure you've got an
> > > appropriately optimized (Release/RelWithDebInfo) build; if one of
> > > the distribution packages came prebuilt with debug binaries,
> > > please let us know which one(s).
> > cmake says it builds RelWithDebInfo, so I guess this one is ok.
> >
> > Â
> >
> > > * You're searching in the entire BPatch_image for GLES2GetError,
> > > which causes the executable and all of its dependent shared
> > > libraries to be searched for the function in question (and likely
> > > over-eagerly parsed). You can constrain this search by looking in
> > > the BPatch_module corresponding to the binary that you expect to
> > > find GLES2GetError in, which should significantly speed up the
> > > instrumentation process.
> > I added code to iterate through the modules and skip the shared
> > libraries. By reflex, I "printf"-ed what shared libs were skipped,
> > only to find that the code wasn't reached.
> > So I added some more printf's, only to find that the functions
> > taking too much time is
> > ÂÂ handle = bpatch.processCreate(name, argv)
> >
> > Source code:Â
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/mutator.C
> > [1]
> >
> > Â
> >
> > > * While it's unlikely that the debug information that's present
> > > needs to be parsed to insert the instrumentation you want, it's
> > > possible that there's a bug causing that to happen.
> > >
> > > If neither the correctness nor the speed fixes I suggest are
> > > helpful to you, if you can run your mutator under valgrind's
> > > massif tool and send me the results, I may have some insight into
> > > the problem.
> > I've made a small mutatee to be able to get the massif output, since
> > mutating chromium doesn't work, so
> > this is the output generated on the test mutatee.
> >
> > massif.out:
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/massif.out.17000
> > [2]
> > stdoutput:ÂÂ
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/massif.log
> > [3]
> two different gdb backtraces.
> This one is somewhat at the beginning of chrome instrumentation:
> Â http://pastebin.com/M2WR4xiC [4]
>
> and this one is after a few tens of seconds:
> Â http://pastebin.com/gnz9Eqps [5]
>
>
>
> Links:
> ------
> [1]
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/mutator.C
> [2]
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/massif.out.17000
> [3]
> https://raw.githubusercontent.com/groleo/dyninst-experiments/master/massif.log
> [4] http://pastebin.com/M2WR4xiC
> [5] http://pastebin.com/gnz9Eqps