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

[Luis Machado <luis_gustavo@mentor.com>]

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