This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 5/8] Doc for agent


> Date: Tue, 24 Jan 2012 08:33:37 +0800
> From: Yao Qi <yao@codesourcery.com>
> CC: <gdb-patches@sourceware.org>
> 
> >> +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."

OK.

> 
> >>                             @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.

It might be a good idea to say that.  Otherwise, the wording sounds as
if using the agent solves this problem 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.

What can it do in addition?  I don't think your new text said anything
about that.

> I don't mind putting it back at the
> the beginning of chapter "Debugging Agent" as another problem statement.

I think it should be the only statement of the problem.  If the agent
has additional benefits, their description should be added to the
above text.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]