From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15012 invoked by alias); 16 May 2012 20:52:28 -0000 Received: (qmail 15004 invoked by uid 22791); 16 May 2012 20:52:28 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 20:52:15 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4GKqELD013900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 16:52:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4GKqCbH030822; Wed, 16 May 2012 16:52:13 -0400 Message-ID: <4FB4137C.6000107@redhat.com> Date: Wed, 16 May 2012 20:52:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stan Shebs CC: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v2] dynamic printf References: <4FA8BC97.2000801@earthlink.net> <4FA8D049.109@codesourcery.com> <4FB12A8E.7040905@earthlink.net> <87ipfvop8i.fsf@fleche.redhat.com> <4FB41216.2080508@earthlink.net> In-Reply-To: <4FB41216.2080508@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-05/txt/msg00628.txt.bz2 On 05/16/2012 09:46 PM, Stan Shebs wrote: >> I thought this approach would break "next"ing over a dprintf location. > > Indeed, thus this part of the introduction to this patch: :-) > > "... Joel previously noted a problem with the "continue" in the command list, which is > that stepping/nexting over a dprintf becomes a continue instead (this is a problem for > general breakpoint command lists as well). I tinkered with bpstats a bit, but didn't > come up with a good solution. This is normally handled by the bpstat saying "don't stop". Doesn't that work for this? Why? > Ironically, the agent version doesn't have this problem, because the resume happens automatically inside GDBserver, and GDB is oblivious. That's sort of what happens when the bpstat returns "don't stop for this". -- Pedro Alves