From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13924 invoked by alias); 4 Jan 2012 15:24:02 -0000 Received: (qmail 13896 invoked by uid 22791); 4 Jan 2012 15:23:59 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 15:23:45 +0000 Received: by vcge1 with SMTP id e1so15058583vcg.0 for ; Wed, 04 Jan 2012 07:23:44 -0800 (PST) Received: by 10.220.148.201 with SMTP id q9mr12770212vcv.33.1325690624512; Wed, 04 Jan 2012 07:23:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.3.130 with HTTP; Wed, 4 Jan 2012 07:23:23 -0800 (PST) In-Reply-To: <201201041449.q04EnCCO026716@d06av02.portsmouth.uk.ibm.com> References: <201201041449.q04EnCCO026716@d06av02.portsmouth.uk.ibm.com> From: Kevin Pouget Date: Wed, 04 Jan 2012 15:24:00 -0000 Message-ID: Subject: Re: [RFC] Python Finish Breakpoints To: Ulrich Weigand Cc: Tom Tromey , gdb-patches@sourceware.org, brobecker@adacore.com 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: 2012-01/txt/msg00142.txt.bz2 On Wed, Jan 4, 2012 at 3:49 PM, Ulrich Weigand wrote: > Kevin Pouget wrote: > >> =A0 =A0 =A0 * gdb.python/py-finish-breakpoint2.cc: New file. >> =A0 =A0 =A0 * gdb.python/py-finish-breakpoint2.exp: New file. >> =A0 =A0 =A0 * 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 cat= ch() > 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 except= ion > > 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. =A0However, when an > exception is thrown and then caught, execution continues at a different > call site (in the catch block). =A0There's now two possibilities: > > =A0try > =A0 =A0{ > =A0 =A0 =A0throw_exception_1 (10); > =A0 =A0} > =A0catch (const int *e) > =A0 =A0{ > =A0 =A0 =A0 =A0std::cerr << "Exception #" << *e << std::endl; > =A0 =A0} > =A0i +=3D 1; /* Break after exception 1. =A0*/ > > > A) The instruction immediately following the "call" instruction to > =A0 throw_exception_1 is actually already one of the instructions used > =A0 to implement the "i +=3D 1" line, and code flow after executing the > =A0 catch block branches back to that location. =A0I.e. we have a call > =A0 graph along the lines of: > > =A0 [...] > =A0 =A0 =A0 call throw_exception_1 (10) =A0[ set up catch block at Lc ] > =A0 Lx: compute i +=3D 1 > =A0 [...] > > =A0 Lc: call std:cerr << ... > =A0 =A0 =A0 goto Lx > > =A0and the finish breakpoint gets set just at label Lx, and it will > =A0get hit both after a regular return and after an exception. > > B) The instruction immediately following the "call" instruction > =A0 is still part of the (clean up after the) call, or some other > =A0 code flow instruction, and the instructions used to implement > =A0 "i +=3D 1" are elsewhere. =A0I.e. the call graph looks more like: > > =A0 [...] > =A0 =A0 =A0 call throw_exception_1 (10) =A0[ set up catch block at Lc ] > =A0 Lx: goto Ly > > =A0 Lc: call std:cerr <<< ... > > =A0 Ly: compute i +=3D 1 > =A0 [...] > > =A0 In this case the finish breakpoint gets set at Lx, which *never* > =A0 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. =A0Note 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? =A0It would certainly be good to properly support > this feature, but until we do, I'd suggest this test case should be > disabled ... Hello, thanks for spotting and explaining this bug I can say at least that there is no code to handle this situation in my patch. One thing I wonder is what's the situation C which passes the test in my environment ? (x86_64) My knowledge about C++ is quite limited, but based on your descriptions, a proper support would involve another breakpoint, set at Lc, to disable the FinishBreakpoint ... but I'm not sure how computable this Lc is. I'll let Tom answer about what to do with the testsuite. Thanks, Kevin