From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19452 invoked by alias); 24 Oct 2009 23:05:55 -0000 Received: (qmail 19443 invoked by uid 22791); 24 Oct 2009 23:05:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 24 Oct 2009 23:05:50 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 466B09065; Sat, 24 Oct 2009 16:05:45 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 3E635DC058; Sat, 24 Oct 2009 16:05:45 -0700 (PDT) Message-ID: <4AE386A1.2080806@vmware.com> Date: Sun, 25 Oct 2009 00:30:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Paul Pluzhnikov CC: Eli Zaretskii , Pedro Alves , "gdb@sourceware.org" Subject: Re: Breakpoint commands References: <83iqe4g9t2.fsf@gnu.org> <200910241704.00548.pedro@codesourcery.com> <83hbtog3fv.fsf@gnu.org> <8ac60eac0910241229g44d8d657ve8f888f1a606790b@mail.gmail.com> In-Reply-To: <8ac60eac0910241229g44d8d657ve8f888f1a606790b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00357.txt.bz2 Paul Pluzhnikov wrote: > On Sat, Oct 24, 2009 at 9:30 AM, Eli Zaretskii wrote: >>> From: Pedro Alves >>> Date: Sat, 24 Oct 2009 17:03:59 +0100 >>> >>> "You can use breakpoint commands to start your program up again. Simply >>> use the @code{continue} command, or @code{step}, or any other command >>> that resumes execution. >>> >>> Any other commands in the command list, after a command that resumes >>> execution, are ignored. This is because any time you resume execution >>> (even with a simple @code{next} or @code{step}), you may encounter >>> another breakpoint---which could have its own command list, leading to >>> ambiguities about which list to execute." >> Thanks for reminding me. We ought to display a warning when any >> commands are used on the command list beyond those which resume. > > FWIW, I very often would like to do this: > > int foo(int x) { ... } > > break foo > command 1 > print x > finish ## expecting it to print return of foo() > continue > > and that last 'continue' of course doesn't work, so I have to sit an > press enter all day :-( > > The argument of "you may encounter other breakpoints ..." is (IMHO) a > weak one: I *don't* in fact encounter any other breakpoints. I think the "argument" that you may encounter other breakpoints is in part a rationalization. In reality, it seems to me that we just didn't want to make breakpoint command handling (which would have included handle_inferior_event) recursive. > It's probably not too difficult to implement "if you encounter any > other breakpoint with its own command list while executing the > original command list, the original command list is abandoned" policy. > I'll open a feature request unless somebody explains why this would be > a bad idea. > > Thanks,