On Mon, Nov 17, 2014 at 3:13 PM, Adrian M Negreanu <[email protected]> wrote:
> > > 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 > two different gdb backtraces. This one is somewhat at the beginning of chrome instrumentation: http://pastebin.com/M2WR4xiC and this one is after a few tens of seconds: http://pastebin.com/gnz9Eqps
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
