From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13875 invoked by alias); 16 May 2012 22:25:13 -0000 Received: (qmail 13864 invoked by uid 22791); 16 May 2012 22:25:12 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-mealy.atl.sa.earthlink.net (HELO elasmtp-mealy.atl.sa.earthlink.net) (209.86.89.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 22:25:00 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SUmeR-0002jn-Lt for gdb-patches@sourceware.org; Wed, 16 May 2012 18:24:59 -0400 Message-ID: <4FB4293B.9030303@earthlink.net> Date: Wed, 16 May 2012 22:25:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: 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> <4FB4137C.6000107@redhat.com> In-Reply-To: <4FB4137C.6000107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940db6832b60842c9464c48108232bd4559350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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-05/txt/msg00640.txt.bz2 On 5/16/12 1:52 PM, Pedro Alves wrote: > 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? > Basically if you set bs->stop to 0, command lists don't get run. It's a little convoluted, because the code does go into bpstat_do_actions, but nothing happens there because the copy of b->commands to bs->commands in bpstat_stop_status only happens if bs->stop. That's why I'm thinking of a special command / pseudo-command for the command list; we don't necessarily want to say that we haven't stopped, because that meaning is typically reserved for "yes we hit the trap, but pretend it never happened". Instead, we want the effect of hitting the breakpoint, and then go back to making progress on whichever command we were doing. An alternative is to make bs->stop a three-state, but that seems like a really bad idea for an area of code that is already rather funky. Stan