Re: [patch 5/8] Doc for agent

[Yao Qi <yao at codesourcery dot com>]

On 01/24/2012 01:35 AM, Eli Zaretskii wrote:

Eli,
Thanks for the review.

> 
>> +multi-threaded program becomes more and more popular, there should be more
>                   ^^^^^^^^^^^^^^^
> "programs become"
> 
>> +and more bugs that only manifest themselves at full speed, for example, thread
>> +races.
> 
> I don't really agree that the issue here is "low speed" vs "full
> speed".  Rather, the issue is that the timeline of the running program
> is modified by the debugger, when it stops some or all of the threads,
> single-steps some of them, etc.  Disrupting the original timeline can
> completely modify the behavior and conceal bugs that depend on timing.
> 

Agreed.

>> +the bug.  In order to overcome the interference, we should reduce the number of
>> +operations debugger performed.
>               ^^^^^^^^^^^^^^^^^^
> "preformed by the debugger".
> 
> Again, I think the issue is not the number of operations, but
> interference with the program's timing.
> 

Yes, the issue is the interference with the program's timing.  We want
to fix this issue, to some extent, by reducing the number of operations
here.  Of course, there are other approaches to reduce interference.

How about change this sentence like this,

"In order to reduce the interference with the program, we can reduce the
number of operations performed by the debugger."

>>                             @dfn{Agent}, a shared library, is running within
>> +the same process with inferior, and is able to perform some debugging operations
>> +itself.  As a result, debugger is only involved when necessary, and performance
>> +of debugging can be improved accordingly.
> 
> But this is a half-measure, isn't it?  The agent will still stop or
> slow down the program's threads, and so still influences its timeline,
> right?
> 

Right.  Interference can be reduced, but can't be removed completely.

>> -In some applications, it is not feasible for the debugger to interrupt
>> -the program's execution long enough for the developer to learn anything
>> -helpful about its behavior.  If the program's correctness depends on its
>> -real-time behavior, delays introduced by a debugger might cause the
>> -program to fail, even when the code itself is correct.  It is useful to
>> -be able to observe the program's behavior without interrupting it.
> 
> See, this text describes the issue more correctly, IMO, but it looks
> like you deleted it and not moved it to the new chapter.

I remove this paragraph because it fits to the concept of tracepoint
("observer the program's behavior without interrupting it"), and the
agent work can do more than that.  I don't mind putting it back at the
the beginning of chapter "Debugging Agent" as another problem statement.

-- 
Yao (éå)