From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19693 invoked by alias); 7 Apr 2008 15:32:32 -0000 Received: (qmail 19684 invoked by uid 22791); 7 Apr 2008 15:32:32 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Apr 2008 15:32:12 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m37FS9IJ029198; Mon, 7 Apr 2008 11:28:09 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m37FS83g031010; Mon, 7 Apr 2008 11:28:08 -0400 Received: from opsy.redhat.com (vpn-248-120.boston.redhat.com [10.13.248.120]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m37FS7S4014372; Mon, 7 Apr 2008 11:28:08 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 702393780DB; Mon, 7 Apr 2008 09:28:06 -0600 (MDT) To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: 3/5 - Rework stepping over longjmp support References: <200804070331.14538.pedro@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Mon, 07 Apr 2008 19:43:00 -0000 In-Reply-To: <200804070331.14538.pedro@codesourcery.com> (Pedro Alves's message of "Mon\, 7 Apr 2008 03\:31\:14 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (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: 2008-04/txt/msg00138.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> The longjmp inside hidden_longjmp is going to land inside Pedro> hidden_longjmp. GDB could ignore it leave the step-resume Pedro> breakpoint at the return of hidden_longjmp and pretend Pedro> that longjmp was never seen. Think of stepping over a function Pedro> in gdb's sources, and an exception being thrown and caught all Pedro> somewhere inner to the function you're stepping. I've Pedro> implemented a prototype patch that does this. Does anyone Pedro> else think that behaviour is useful? I do. Speaking as a user, this is the behavior I expect. That is, if I 'next' over a function call (and assuming the "easy" case -- no user breakpoints or watchpoints or the like), anything that happens during that function call should be invisible to me. And, in my view, the inferior should stop at the "next" instruction after the function call; if that is in an outer frame, then I want to stop there. Ideally, of course, all this should happen for exceptions in c++ and java as well :-). FWIW the c++ case is more important to me ... but I'm rather fascinated by this patch series because I didn't know this code even existed, and it makes handling exceptions seem more possible. Pedro> (I'm aware that any Pedro> smartness we add can be defeated by longjmp changing stacks, Pedro> or stuff like debugging coroutines implemented with set/longjmp, Pedro> but those feel like rare enough that a smart mode could be Pedro> the default and useful most of (almost-all) the times.) As long as folks doing unusual stuff like this can cope for themselves, I think your proposed behavior is preferable. Tom