From: Eli Zaretskii <eliz@gnu.org>
To: luis_gustavo@mentor.com
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC stub-side break conditions 0/5] General info
Date: Fri, 06 Jan 2012 07:53:00 -0000 [thread overview]
Message-ID: <831urdp8vb.fsf@gnu.org> (raw)
In-Reply-To: <4F05B9FE.1000500@mentor.com>
> Date: Thu, 05 Jan 2012 12:55:58 -0200
> From: Luis Machado <luis_gustavo@mentor.com>
>
> This patch series adds support and required machinery to enable
> breakpoint condition evaluation on the stub's side instead of solely in
> the host's side.
>
> When the evaluation is done on the stub's side, we eliminate all the
> useless stub -> GDB trap notifications that happen when the condition is
> false, potentially improving the speed of debugging on slower connections.
But the downside is that the stub has more work to do, and therefore
can potentially disrupt the timeline of the program being debugged.
Is this feature really worth it? How "slow" should a slow connection
be before this becomes a win? are there types of programs where this
mode should never be used for fear of interfering with the program's
timings?
> A new switch was added to make it possible to choose between gdb/stub
> evaluation modes: set/show breakpoint condition-evaluation. It defaults
> to "auto". "auto" means "gdb" whenever the stub can't handle breakpoint
> condition evaluation or when the expression can't be evaluated by the
> agent expression machinery. "auto" means "stub" when the remote stub
> supports evaluating conditions and if the expressions generate valid
> agent expression bytecodes.
Isn't it better to make the default be "off", i.e. keep the previous
modus operandi?
next prev parent reply other threads:[~2012-01-06 7:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 14:56 Luis Machado
2012-01-06 7:53 ` Eli Zaretskii [this message]
2012-01-06 9:10 ` Joel Brobecker
2012-01-06 10:49 ` Luis Machado
2012-01-06 20:12 ` Stan Shebs
2012-01-06 20:48 ` Eli Zaretskii
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=831urdp8vb.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=luis_gustavo@mentor.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).