On Sat, Nov 15, 2014 at 12:03 AM, Bill Williams <[email protected]> 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
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
