From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30074 invoked by alias); 4 Jan 2012 14:49:34 -0000 Received: (qmail 30043 invoked by uid 22791); 4 Jan 2012 14:49:33 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 14:49:18 +0000 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 14:49:16 -0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com ([9.149.38.129]) by e06smtp17.uk.ibm.com ([192.168.101.147]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 14:49:14 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q04EnEMv2420834 for ; Wed, 4 Jan 2012 14:49:14 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q04EnDOP026951 for ; Wed, 4 Jan 2012 07:49:14 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q04EnCCO026716; Wed, 4 Jan 2012 07:49:12 -0700 Message-Id: <201201041449.q04EnCCO026716@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 04 Jan 2012 15:49:12 +0100 Subject: Re: [RFC] Python Finish Breakpoints To: kevin.pouget@gmail.com (Kevin Pouget) Date: Wed, 04 Jan 2012 14:49:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com (Tom Tromey), gdb-patches@sourceware.org, brobecker@adacore.com In-Reply-To: from "Kevin Pouget" at Dec 09, 2011 10:31:45 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010414-0542-0000-0000-00000091DEBC 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/msg00138.txt.bz2 Kevin Pouget wrote: > * gdb.python/py-finish-breakpoint2.cc: New file. > * gdb.python/py-finish-breakpoint2.exp: New file. > * gdb.python/py-finish-breakpoint2.py: New file. I'm seeing those fail on various platforms (i386, ppc, ppc64): FAIL: gdb.python/py-finish-breakpoint2.exp: check FinishBreakpoint in catch() FAIL: gdb.python/py-finish-breakpoint2.exp: check finish BP removal FAIL: gdb.python/py-finish-breakpoint2.exp: continue to second exception FAIL: gdb.python/py-finish-breakpoint2.exp: set FinishBP after the exception However in other cases the test succeeds -- this appears to be related to the particular compiler version that's being used. The problem is that the finish-breakpoint mechanism sets a breakpoint on the regular return address of the current frame, i.e. the instruction where the "call" instruction would return normally. However, when an exception is thrown and then caught, execution continues at a different call site (in the catch block). There's now two possibilities: try { throw_exception_1 (10); } catch (const int *e) { std::cerr << "Exception #" << *e << std::endl; } i += 1; /* Break after exception 1. */ A) The instruction immediately following the "call" instruction to throw_exception_1 is actually already one of the instructions used to implement the "i += 1" line, and code flow after executing the catch block branches back to that location. I.e. we have a call graph along the lines of: [...] call throw_exception_1 (10) [ set up catch block at Lc ] Lx: compute i += 1 [...] Lc: call std:cerr << ... goto Lx and the finish breakpoint gets set just at label Lx, and it will get hit both after a regular return and after an exception. B) The instruction immediately following the "call" instruction is still part of the (clean up after the) call, or some other code flow instruction, and the instructions used to implement "i += 1" are elsewhere. I.e. the call graph looks more like: [...] call throw_exception_1 (10) [ set up catch block at Lc ] Lx: goto Ly Lc: call std:cerr <<< ... Ly: compute i += 1 [...] In this case the finish breakpoint gets set at Lx, which *never* gets executed after an exception. It seems to me that current GDB code does not (even attempt to) properly handle the "finish" command and/or the new finish-breakpoint capability in the presence of exceptions. Note that even in case A) above, where the finish breakpoint does hit, it arguably hits in the wrong location: at the "finish" of the throw_exception_1 line, execution continues *in the catch block*, so we should stop at the start of the catch block instead of after it has completed. Am I missing some piece of GDB code that attempts to handle this, and is just malfunctioning? It would certainly be good to properly support this feature, but until we do, I'd suggest this test case should be disabled ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com