Presumably you're running the CodeCoverage tool in two steps: 1) Rewriting
the binary 2) Running the rewritten binary. All of the analysis/rewriting
overheads are in step 1, and the instrumentation overhead can be measured
just by timing step 2.
If you're getting 50x overhead on just step 2 then something's very wrong.
I've got my own codeCoverage tool (which I unfortunately can't share yet)
and I only see 10% overhead.
Just an educated guess--I frequently see big overheads associated with
trampoline guards. Dyninst should have realized trampoline guards are
unnecessary for codeCoverage and not emited them. But if something went
wrong you can manually turn them off by putting a call to:
bpatch.setTrampRecursive(true);
Near the top of codeCoverage.C's main() function. If that makes a
difference then let the list know. That implies there's a bug that should
be investigated.
-Matt
On Mon, 21 Jul 2014, Buddhika Chamith Kahawitage Don wrote:
I just measured the time it took for a single run. Is there a way to get the
time it took for initialization only so that I can get an idea of just the
run-time overhead?
Thanks
Bud
On Mon, Jul 21, 2014 at 7:58 AM, Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:
Hi -
> [...] ÂI was using the CodeCoverage tool [2] for
> instrumentation. But it's taking way too higher time than the
> unprofiled run. (More than a 50x slow down) [...]
Are you measuring steady-state overheads only, or else are you
including the one-time analysis too? ÂThe latter can be quite
large, but you pay it only once per startup.
- FChE
|