From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15107 invoked by alias); 12 May 2011 11:29:27 -0000 Received: (qmail 15088 invoked by uid 22791); 12 May 2011 11:29:25 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_GJ,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 May 2011 11:29:11 +0000 Received: by vws4 with SMTP id 4so1363493vws.0 for ; Thu, 12 May 2011 04:29:10 -0700 (PDT) Received: by 10.220.59.138 with SMTP id l10mr23820vch.138.1305199750102; Thu, 12 May 2011 04:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.188.139 with HTTP; Thu, 12 May 2011 04:28:50 -0700 (PDT) In-Reply-To: References: From: Kevin Pouget Date: Thu, 12 May 2011 11:29:00 -0000 Message-ID: Subject: Re: [RFC] Python Finish Breakpoints To: pmuldoon@redhat.com Cc: gdb@sourceware.org, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-05/txt/msg00307.txt.bz2 thanks for these useful feedbacks, I will try to better understand what can be wrong/unusual with the situations you described and prepare some tests to catch it. But globally, my thoughts when I prepared this interface were that it shouldn't be much different from a classic breakpoint. I'm not really familiar with C++ mechanisms, but I can't see (right now, but I'll investigate it) how it differs from setting a BP on the frame above, checking for recursion upon BP hit and checking for the scope every once in a while. for instance, to talk about what I know > What happens if a longjmp occurs? nothing! obj->out_of_scope() will be triggered by `observer_notify_stop' and the script will have the ability to obj->delete() the breakpoint if it thinks it won't be useful anymore > An exec? nothing/the same as above, out_of_scope() will be triggered at the next stop, I don't know off the top of my head what GDB does with BPs on exec(), but the same would happen with FinishBreakpoint I'll prepare the tests for all these situations and I'll see if it is 'at easy' as I thought thanks, Kevin -- > There are questions arising on how these breakpoints cope when the > inferior jumps unexpectedly. =A0I can think of two examples of this > behavior during inferior function calls. > > * What happens with your breakpoint when you perform an inferior function > =A0call on a C++ function, and that function raises an exception that is > =A0normally and legally processed by an out-of-frame exception handler? > =A0This question arises as it triggers special behavior in GDB. =A0The > =A0problem originates from the dummy-frame created by GDB. =A0It insulate= s the > =A0out-of-frame exception handler from the exception raising code, and > =A0the default C++ handler terminates the inferior. =A0GDB detects this at > =A0present, and rewinds the stack back to the original location before the > =A0function call. =A0What happens, as in your example, if the breakpoint = is > =A0in this inferior function call? =A0This unwinding behavior related to a > =A0C++ inferior is 'on' by default in GDB. > > * The other related example is what happens when a signal is delivered > =A0to the inferior during the inferior function call? =A0Presently GDB wi= ll > =A0stop with an error message. =A0However the user can turn unwinding 'on' > =A0in this scenario too. =A0This signal handling unwinding is 'off' by > =A0default. > > There are other scenarios and state changes to consider. =A0What happens = if > a longjmp occurs? An exec? > > So the behavior is subtle when dealing with inferior changes. =A0So to > prove this new breakpoint type is robust, you would need to provide > test-cases of this kind of proven behavior in your patch. > > Apologies to Tom is I misquoted or mis-phrased our conversation. ;) > > Cheers, > > Phil >