From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12885 invoked by alias); 10 Jun 2009 18:49:30 -0000 Received: (qmail 12874 invoked by uid 22791); 10 Jun 2009 18:49:29 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 18:49:24 +0000 Received: (qmail 17206 invoked from network); 10 Jun 2009 18:49:22 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2009 18:49:22 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFC: next/finish/etc -vs- exceptions Date: Wed, 10 Jun 2009 18:49:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , Joel Brobecker References: <200906101848.04782.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906101950.36575.pedro@codesourcery.com> 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: 2009-06/txt/msg00271.txt.bz2 On Wednesday 10 June 2009 19:29:23, Tom Tromey wrote: > The intent is to compare the "next"ing frame with the target frame of > the exception. Exceptions throw up to or past the nexting frame > should be caught be gdb. Right, this is the bit where comparing SP or FP pointers directly bites back (other than it is not arch portable to address SP or FP directly). The simplest replacement is to check if the "next"ing frame is still in the frame chain (with frame_find_by_id). If it is, then you know that the target frame is inner to the "next"ing frame. If something goes wrong with gdb's unwinding, you'll get a false positive and just stop the inferior in an inner frame (thus, the back case isn't runaway process, but spurious stop). > I don't see how this works for longjmp. From the code it looks like > any longjmp is caught... is that the case? Yes, that's the case. > I suppose the failing case for exception unwinding is if the inferior > stops in a signal handler on a separate stack, then the user "next"s > over a throw in that handler. =A0Does that sound correct? Yes. Or, if you "next" in base code, and a signal (set to "pass nostop") is caught in the meantime, the inferiors switches to an altstack, and then the signal handler in the inferior throws. --=20 Pedro Alves