From: Stan Shebs <stanshebs@earthlink.net>
To: gdb-patches@sourceware.org
Subject: Re: [RFC stub-side break conditions 0/5] General info
Date: Fri, 06 Jan 2012 20:12:00 -0000 [thread overview]
Message-ID: <4F0755A0.9050604@earthlink.net> (raw)
In-Reply-To: <831urdp8vb.fsf@gnu.org>
On 1/5/12 11:50 PM, Eli Zaretskii wrote:
>> 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?
>
For a uniprocessor, target-side evaluation is likely to be a mixed bag;
it will be a win for conditional breakpoints in inner loops, but there
is a distinct heisenbug possibility, and it will likely be standard
advice to go back to host-side evaluation if the code is racy or
generally being erratic.
For multicore, target-side enables debugging usages that have simply not
been possible before, such as a conditional breakpoint on 100 cores.
Even if half the cores are being slowed down by evaluating the
conditional test, it still beats the traffic jam of GDB reading and
writing packets for each core!
The big picture is that all of Mentor's planned GDB development work for
this year targets systems with a *minimum* of 16 cores, and ranging up
to 1000 cores. So we're going to be focused on solving a variety of
scale-up problems.
Stan
next prev parent reply other threads:[~2012-01-06 20:12 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
2012-01-06 10:49 ` Luis Machado
2012-01-06 20:12 ` Stan Shebs [this message]
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=4F0755A0.9050604@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=gdb-patches@sourceware.org \
/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).