From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25970 invoked by alias); 6 Jan 2012 09:10:31 -0000 Received: (qmail 25961 invoked by uid 22791); 6 Jan 2012 09:10:30 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 09:10:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3960F2BAFC1; Fri, 6 Jan 2012 04:10:13 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oH9GfIiomJhS; Fri, 6 Jan 2012 04:10:13 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 01FD42BB09A; Fri, 6 Jan 2012 04:10:11 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8CC54145615; Fri, 6 Jan 2012 13:09:57 +0400 (RET) Date: Fri, 06 Jan 2012 09:10:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: luis_gustavo@mentor.com, gdb-patches@sourceware.org Subject: Re: [RFC stub-side break conditions 0/5] General info Message-ID: <20120106090957.GK2730@adacore.com> References: <4F05B9FE.1000500@mentor.com> <831urdp8vb.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831urdp8vb.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00232.txt.bz2 > 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