From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32308 invoked by alias); 4 Jan 2012 16:29:20 -0000 Received: (qmail 32299 invoked by uid 22791); 4 Jan 2012 16:29:19 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,TW_GJ,TW_TJ X-Spam-Check-By: sourceware.org Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 16:29:00 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 16:28:59 -0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com ([9.149.38.233]) by e06smtp10.uk.ibm.com ([192.168.101.140]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 16:28:57 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q04GSu7c1564722 for ; Wed, 4 Jan 2012 16:28:56 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 q04GSumv012626 for ; Wed, 4 Jan 2012 09:28:56 -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 q04GSs8r012576; Wed, 4 Jan 2012 09:28:54 -0700 Message-Id: <201201041628.q04GSs8r012576@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 04 Jan 2012 17:29:03 +0100 Subject: Re: [RFC] Python Finish Breakpoints To: kevin.pouget@gmail.com (Kevin Pouget) Date: Wed, 04 Jan 2012 16:29: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 Jan 04, 2012 04:23:23 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010416-4966-0000-0000-0000010E5FFC 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/msg00149.txt.bz2 Kevin Pouget wrote: > 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) Hmm, with C the problem potentially exists as well: if (setjmp (env) == 0) /* longjmp caught */ { call_longjmp (&env); } else j += 1; /* after longjmp. */ The finish breakpoint is set immediately after the call to call_longjmp, which may or may not coincide with the first instruction of "j += 1". I guess since the compiler's control flow graph is much simpler as there are no implicit exception edges (rather, setjmp is a "regular" function that just happens to "return twice"), it is more likely for GCC to arrange the resulting assembler in the sequence where everything appears to work ... You might be able to force the problem to consistently appear by adding extra code after call_longjmp, e.g. like so: if (setjmp (env) == 0) /* longjmp caught */ { call_longjmp (&env); some_other_stuff (); } else j += 1; /* after longjmp. */ On the other hand, (at least on some platforms), GDB will actively track calls to longjmp by setting a breakpoint on longjmp and then stepping through until the destination. This might give GDB a chance to notice that the finish breakpoint has gone out of scope by the longjmp, and trigger the break then. That would probably be the best way to implement this feature anyway ... > 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. Not very; you could attempt to decode the exception tables, but those are platform-specific. It might be preferable to handle "throw" similar to how we handle "longjmp", see above. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com