From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3646 invoked by alias); 10 Jun 2009 18:32:04 -0000 Received: (qmail 3631 invoked by uid 22791); 10 Jun 2009 18:32:02 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 18:31:53 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5AITRHV029806; Wed, 10 Jun 2009 14:29:27 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5AITPxC029942; Wed, 10 Jun 2009 14:29:26 -0400 Received: from opsy.redhat.com (vpn-13-36.rdu.redhat.com [10.11.13.36]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5AITOwW017454; Wed, 10 Jun 2009 14:29:25 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 87CB737817A; Wed, 10 Jun 2009 12:29:23 -0600 (MDT) To: Pedro Alves Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , Joel Brobecker Subject: Re: RFC: next/finish/etc -vs- exceptions References: <200906101806.31977.pedro@codesourcery.com> <20090610171328.GA32661@caradoc.them.org> <200906101848.04782.pedro@codesourcery.com> From: Tom Tromey Reply-To: Tom Tromey Date: Wed, 10 Jun 2009 18:32:00 -0000 In-Reply-To: <200906101848.04782.pedro@codesourcery.com> (Pedro Alves's message of "Wed\, 10 Jun 2009 18\:48\:04 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00270.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Oh, C++ exceptions across signals, neat. Didn't think of that. Does that work if you specify a signal stack? I don't know. Pedro> Other than the cross-arch exceptions, I was thinking of things Pedro> like using longjmp for continuations and coroutines, and tricks Pedro> like that. There may be clever ways to do such things with C++ Pedro> exceptions, I don't know then. I don't think so. But I am prepared to be surprised. Pedro> Anyway, not wanting to finger-point I was refering to things like Pedro> these in the patch: Pedro> + /* We use the current stack pointer and not the CFA here, Pedro> + because the unwinder seems to compute the callee's CFA, and Pedro> + so the breakpoint does not trigger. */ Pedro> + stack_ptr = get_frame_sp (frame); This is bogus, btw, because for the comparison to work properly we must compute the Dwarf CFA. There's currently no way that I know of to do this, so presumably some kind of extension to the frame API will be needed. Pedro> + if (!nexting_cfa Pedro> + || gdbarch_inner_than (arch, cfa, nexting_cfa)) Pedro> + { Pedro> + /* Not an interesting exception. */ Pedro> + break; Pedro> + } Pedro> Which I guessed should be using frame_id comparisions, and Pedro> something other than gdbarch_inner_than, frame_find_by_id perhaps Pedro> (that does require a well behaved unwinder). I'm not much Pedro> an expert on C++ unwinding, and haven't really studied the patch, Pedro> so I don't exactly what is being compared here. 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. I don't see how this works for longjmp. From the code it looks like any longjmp is caught... is that the case? I assume I'm missing something, would you mind point it out? 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. Does that sound correct? Thanks for the hint about frame_id comparisons. I will look into that. Tom