* Re: [RFC stub-side break conditions 0/5] General info
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
2 siblings, 0 replies; 6+ messages in thread
From: Joel Brobecker @ 2012-01-06 9:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luis_gustavo, gdb-patches
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC stub-side break conditions 0/5] General info
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
2 siblings, 0 replies; 6+ messages in thread
From: Luis Machado @ 2012-01-06 10:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches, brobecker
On 01/06/2012 05:50 AM, 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?
Thanks for the feedback (cc-ing Joel as well).
I apologize for not being perfectly clear about the motivation for this
patch.
While this may not represent a huge boost in performance over the
previous breakpoint condition evaluation method, it a step towards
agent-based evaluations, see
http://sourceware.org/ml/gdb/2011-11/msg00014.html.
Consider this a preparation patch to enable breakpoint condition
evaluation by the target agent. That mode of evaluation will have much
more noticeable effects due to the fact that GDB/GDBServer are not
involved in the evaluation process itself, but we need some
infrastructure before moving to that kind of operation.
For example, GDBServer needs to receive the conditional expressions and
needs to understand how to handle them.
This feature also means GDB won't have to be notified everytime a
conditional breakpoint triggers. It will just be notified when the
condition is true, avoiding a number of round trips if the condition is
very specific. In the future, with the aid of the agent, this will
represent a good improvement.
>> 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?
In this case, the old behavior is kept intact with mode "gdb". I'm ok
with keeping it that way, for the sake of potentially slow targets. We
can always reconsider this at a later stage.
Luis
lgustavo@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC stub-side break conditions 0/5] General info
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
2012-01-06 20:48 ` Eli Zaretskii
2 siblings, 1 reply; 6+ messages in thread
From: Stan Shebs @ 2012-01-06 20:12 UTC (permalink / raw)
To: gdb-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC stub-side break conditions 0/5] General info
2012-01-06 20:12 ` Stan Shebs
@ 2012-01-06 20:48 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2012-01-06 20:48 UTC (permalink / raw)
To: Stan Shebs; +Cc: gdb-patches
> Date: Fri, 06 Jan 2012 12:12:16 -0800
> From: Stan Shebs <stanshebs@earthlink.net>
>
> 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!
Thanks. It would be nice to have this explanation in the manual.
^ permalink raw reply [flat|nested] 6+ messages in thread