...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 <[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
[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
_______________________________________________
Dyninst-api mailing list
[email protected]
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
