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

[Stan Shebs <stanshebs at earthlink dot net>]

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