From: Eli Zaretskii <eliz@gnu.org>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 5/8] Doc for agent
Date: Tue, 24 Jan 2012 08:04:00 -0000 [thread overview]
Message-ID: <E1RpZKf-00069K-Vn@fencepost.gnu.org> (raw)
In-Reply-To: <4F1DFC61.2080802@codesourcery.com> (message from Yao Qi on Tue, 24 Jan 2012 08:33:37 +0800)
> 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.
next prev parent reply other threads:[~2012-01-24 5:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 13:37 [patch 0/8] GDB/GDBserver talks with agents Yao Qi
2012-01-23 13:48 ` [patch 1/8] Generalize interaction with agent in gdb/gdbserver Yao Qi
2012-01-30 11:25 ` Yao Qi
2012-02-09 19:21 ` Pedro Alves
2012-02-14 2:41 ` Yao Qi
2012-02-14 10:16 ` Pedro Alves
2012-01-23 13:50 ` [patch 2/8] Add to_use_agent in target_ops Yao Qi
2012-02-09 19:36 ` Pedro Alves
2012-01-23 13:54 ` [patch 3/8] Command `set agent on|off' Yao Qi
2012-01-23 17:14 ` Eli Zaretskii
2012-01-24 0:28 ` Yao Qi
2012-01-24 5:54 ` Eli Zaretskii
2012-01-26 1:32 ` Yao Qi
2012-02-09 20:19 ` Pedro Alves
2012-01-23 13:58 ` [patch 4/8] `use_agent' for remote and QAgent Yao Qi
2012-01-23 17:17 ` Eli Zaretskii
2012-01-26 2:17 ` Yao Qi
2012-01-26 17:43 ` Eli Zaretskii
2012-02-09 19:55 ` Pedro Alves
2012-01-23 14:03 ` [patch 5/8] Doc for agent Yao Qi
2012-01-23 18:12 ` Eli Zaretskii
2012-01-24 0:51 ` Yao Qi
2012-01-24 8:04 ` Eli Zaretskii [this message]
2012-01-26 1:53 ` Yao Qi
2012-01-26 17:15 ` Eli Zaretskii
2012-02-09 19:55 ` Pedro Alves
2012-02-10 13:30 ` Yao Qi
2012-02-10 15:01 ` Pedro Alves
2012-02-10 16:18 ` Yao Qi
2012-02-10 16:28 ` Pedro Alves
2012-02-23 7:51 ` Yao Qi
2012-02-23 19:50 ` Pedro Alves
2012-01-23 14:07 ` [patch 6/8] Agent's capability Yao Qi
2012-01-24 3:49 ` Yao Qi
2012-02-09 20:09 ` Pedro Alves
2012-02-10 12:25 ` Yao Qi
2012-02-10 12:37 ` Pedro Alves
2012-02-10 13:07 ` Yao Qi
2012-01-23 14:29 ` [patch 7/8] Agent capability for static tracepoint Yao Qi
2012-02-09 20:13 ` Pedro Alves
2012-02-10 14:29 ` Yao Qi
2012-02-10 14:56 ` Pedro Alves
2012-01-23 16:03 ` [patch 8/8] Control agent in testsuite Yao Qi
2012-02-09 20:16 ` Pedro Alves
2012-02-05 4:32 ` [ping] [patch 0/8] GDB/GDBserver talks with agents Yao Qi
2012-02-09 19:02 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1RpZKf-00069K-Vn@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox