From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luis_gustavo@mentor.com, gdb-patches@sourceware.org
Subject: Re: [RFC stub-side break conditions 0/5] General info
Date: Fri, 06 Jan 2012 09:10:00 -0000 [thread overview]
Message-ID: <20120106090957.GK2730@adacore.com> (raw)
In-Reply-To: <831urdp8vb.fsf@gnu.org>
> 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?
I do not think that adding computation on the stub would make
things slower. The proposed approach is saving the time spent
communicating between GDB and the stub, and replacings the time
the stub spends *waiting* for GDB to evaluate the condition
(more communication with the stub) by time spent by the stub
evaluating the byte-code condition. The target would have to be
really really slow in order to make that more disruptive than
the current approach.
> Isn't it better to make the default be "off", i.e. keep the previous
> modus operandi?
I would prefer "auto". Otherwise, I do not think that the feature
will get much use. Unless, of course, you happen to be right about
the feature being potentially disruptive.
--
Joel
next prev parent reply other threads:[~2012-01-06 9:10 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
2012-01-06 9:10 ` Joel Brobecker [this message]
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=20120106090957.GK2730@adacore.com \
--to=brobecker@adacore.com \
--cc=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).