On 01/20/2015 11:22 AM, Matthew LeGendre wrote:
The closest you can get is to register a callback that triggers on fork,
then detach from the child in that callback.
There's not really a faster way to disable tracing of children, as
Dyninst needs to clean its instrumentation from child processes before
detaching.
I'm also somewhat curious what aspect of Dyninst's fork behavior is
responsible for the slowdown you're observing, Gerard. Can you tell us a
bit about your use case and more details about why/how Dyninst is
responsible for this slowdown?
Matt is of course correct that if this is a fork without a subsequent
exec, that it's necessary for Dyninst to remove all its instrumentation.
In principle, if we knew that all forks would be followed either by an
immediate exec or a crash, we could dispense with that instrumentation
entirely, but in practice that's not generally a safe assumption.
Another option that may be effective is performing the initial
instrumentation with binary rewriting...that should have substantially
better behavior for what you want re: fork/exec.
-Matt
On Mon, 19 Jan 2015, Gerard wrote:
Hello,
Is it possible to not trace the children created by a mutatee? I want to
avoid the time penalty introduced by dyninst when a mutatee creates a
children.
Thanks,
Gerard
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}