Hi,

Thanks for your answers. I'll try using a callback.

I'm instrumenting a process that at some point compiles a code invoking
gcc trough the system() function. I have made more tests and I see that the
slow down is worse in the first call, does this makes sense?

Those are the times that I observe while I'm instrumenting with dyninst
(just the function that wraps the call to system()):

Compilation time 0: 0.984198
Compilation time 1: 0.080625
Compilation time 2: 0.084245
Compilation time 3: 0.077437
Compilation time 4: 0.084535
Compilation time 5: 0.111851
Compilation time 6: 0.087407
Compilation time 7: 0.090078
Compilation time 8: 0.093158
Compilation time 9: 0.075809

While without dyninst the times are between 0.03 ~ 0.04 seconds.

Gerard

2015-01-20 18:37 GMT+01:00 Bill Williams <[email protected]>:

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

Reply via email to