From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16225 invoked by alias); 6 Jan 2012 07:53:17 -0000 Received: (qmail 16211 invoked by uid 22791); 6 Jan 2012 07:53:14 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 07:53:01 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LXD00C009LRA700@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Fri, 06 Jan 2012 09:52:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.16.185]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXD00CTS9W229C0@a-mtaout21.012.net.il>; Fri, 06 Jan 2012 09:52:51 +0200 (IST) Date: Fri, 06 Jan 2012 07:53:00 -0000 From: Eli Zaretskii Subject: Re: [RFC stub-side break conditions 0/5] General info In-reply-to: <4F05B9FE.1000500@mentor.com> To: luis_gustavo@mentor.com Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <831urdp8vb.fsf@gnu.org> References: <4F05B9FE.1000500@mentor.com> 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/msg00228.txt.bz2 > 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? > 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?