From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20602 invoked by alias); 4 Jan 2012 16:40:35 -0000 Received: (qmail 20397 invoked by uid 22791); 4 Jan 2012 16:40:31 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 04 Jan 2012 16:40:13 +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 q04GdwFv025087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 11:39:58 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q04GdwE2002057; Wed, 4 Jan 2012 11:39:58 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q04Gduqd002071; Wed, 4 Jan 2012 11:39:56 -0500 From: Tom Tromey To: "Ulrich Weigand" Cc: kevin.pouget@gmail.com (Kevin Pouget), gdb-patches@sourceware.org, brobecker@adacore.com Subject: Re: [RFC] Python Finish Breakpoints References: <201201041449.q04EnCCO026716@d06av02.portsmouth.uk.ibm.com> Date: Wed, 04 Jan 2012 16:40:00 -0000 In-Reply-To: <201201041449.q04EnCCO026716@d06av02.portsmouth.uk.ibm.com> (Ulrich Weigand's message of "Wed, 4 Jan 2012 15:49:12 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-01/txt/msg00151.txt.bz2 >>>>> "Ulrich" == Ulrich Weigand writes: Ulrich> The problem is that the finish-breakpoint mechanism sets a breakpoint on Ulrich> the regular return address of the current frame, i.e. the instruction Ulrich> where the "call" instruction would return normally. However, when an Ulrich> exception is thrown and then caught, execution continues at a different Ulrich> call site (in the catch block). There's now two possibilities: [...] I think the test is actually incorrect, and that if it passes, it is only by accident. The test assumes that the "finish" will cause the ExceptionFinishBreakpoint to fire. However, I don't think this makes sense. A Python "finish" breakpoint will only fire if the "finish" returns normally; it might fire "accidentally" if the exception lands at exactly the same spot. So, I think either result -- a call to the stop method or a call to the out_of_scope method -- is ok in this situation. Ulrich> Am I missing some piece of GDB code that attempts to handle this, and Ulrich> is just malfunctioning? It would certainly be good to properly support Ulrich> this feature, but until we do, I'd suggest this test case should be Ulrich> disabled ... We have support for "finish", and other operations in the presence of exceptions. Search for _Unwind_DebugHook (in breakpoint.c and infrun.c). This code only works if you are using a new-enough version of GCC and have debuginfo for libgcc (but once the stap probe patches are in, you will no longer need debuginfo). We could probably augment Python "finish" breakpoints to add a new method that is called in the exception case. Tom