From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10849 invoked by alias); 6 Jan 2012 20:12:32 -0000 Received: (qmail 10836 invoked by uid 22791); 6 Jan 2012 20:12:30 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-kukur.atl.sa.earthlink.net (HELO elasmtp-kukur.atl.sa.earthlink.net) (209.86.89.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 20:12:18 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RjG9B-0001q0-8G for gdb-patches@sourceware.org; Fri, 06 Jan 2012 15:12:17 -0500 Message-ID: <4F0755A0.9050604@earthlink.net> Date: Fri, 06 Jan 2012 20:12:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC stub-side break conditions 0/5] General info References: <4F05B9FE.1000500@mentor.com> <831urdp8vb.fsf@gnu.org> In-Reply-To: <831urdp8vb.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940d55716134fcb94725c7c00dca60aeca3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00247.txt.bz2 On 1/5/12 11:50 PM, Eli Zaretskii wrote: >> Date: Thu, 05 Jan 2012 12:55:58 -0200 >> From: Luis Machado >> >> 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