Re: [DynInst_API:] Unable to instrument chromium

[Adrian M Negreanu <groleo@xxxxxxxxx>]

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

Â

* 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
stdoutput:ÂÂ https://raw.githubusercontent.com/groleo/dyninst-experiments/master/massif.log