[RFC stub-side break conditions 0/5] General info

[RFC stub-side break conditions 0/5] General info

[Luis Machado]

Hi,

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.

Condition evaluation is achieved through the use of the agent expression 
machinery that is already in place for GDBServer. We extend the z0/z1 
packets to carry additional data. In this case it carries the bytecode 
expression that should be used for evaluation. Each z0/z1 packet will 
carry all the conditions for all the locations at an specific address.

If we can't convert an expression into a valid agent expression (due to 
complex types of host-specific data), then we fallback to evaluating the 
condition on GDB's side.

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.

The patch is divided in 5 parts:

Part 1: Documentation bits
Part 2: Protocol and feature changes
Part 3: GDB-specific changes
Part 4: GDBServer tracepoint/agent expression common code cleanup
Part 5: GDBServer breakpoint condition evaluation enablement

Luis
lgustavo@codesourcery.com

Re: [RFC stub-side break conditions 0/5] General info

[Eli Zaretskii]

> 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?

Re: [RFC stub-side break conditions 0/5] General info

[Joel Brobecker]

> 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

Re: [RFC stub-side break conditions 0/5] General info

[Luis Machado]

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

Re: [RFC stub-side break conditions 0/5] General info

[Stan Shebs]

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

Re: [RFC stub-side break conditions 0/5] General info

[Eli Zaretskii]

> 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.