From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30762 invoked by alias); 12 May 2011 10:50:08 -0000 Received: (qmail 30744 invoked by uid 22791); 12 May 2011 10:50:06 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_GJ,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; Thu, 12 May 2011 10:49:48 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4CAnk5O029266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2011 06:49:46 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p4CAnjF2004248; Thu, 12 May 2011 06:49:45 -0400 From: Phil Muldoon To: Kevin Pouget Cc: gdb@sourceware.org, gdb-patches@sourceware.org Subject: Re: [RFC] Python Finish Breakpoints References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Thu, 12 May 2011 10:50:00 -0000 In-Reply-To: (Phil Muldoon's message of "Wed, 11 May 2011 11:31:29 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00306.txt.bz2 Phil Muldoon writes: > Kevin Pouget writes: > >> Any feedback ... ? > Overall I like the idea, but I am unsure of the implementation. I don't > want to unnecessarily bike-shed something before the maintainer have a > had a look at it. I talked with Tom about this on IRC (really we should have done it on the list, but there things happen). I'm sure Tom will also comment. But some things came up that Tom mentioned, and we expanded on, that is important enough to mention now, before you do anymore work. There are questions arising on how these breakpoints cope when the inferior jumps unexpectedly. I can think of two examples of this behavior during inferior function calls. * What happens with your breakpoint when you perform an inferior function call on a C++ function, and that function raises an exception that is normally and legally processed by an out-of-frame exception handler? This question arises as it triggers special behavior in GDB. The problem originates from the dummy-frame created by GDB. It insulates the out-of-frame exception handler from the exception raising code, and the default C++ handler terminates the inferior. GDB detects this at present, and rewinds the stack back to the original location before the function call. What happens, as in your example, if the breakpoint is in this inferior function call? This unwinding behavior related to a C++ inferior is 'on' by default in GDB. * The other related example is what happens when a signal is delivered to the inferior during the inferior function call? Presently GDB will stop with an error message. However the user can turn unwinding 'on' in this scenario too. This signal handling unwinding is 'off' by default. There are other scenarios and state changes to consider. What happens if a longjmp occurs? An exec? So the behavior is subtle when dealing with inferior changes. So 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