From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4768 invoked by alias); 12 Jun 2007 12:05:35 -0000 Received: (qmail 4754 invoked by uid 22791); 12 Jun 2007 12:05:34 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Jun 2007 12:05:32 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 70833982DE; Tue, 12 Jun 2007 12:05:30 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 16CA9982DC; Tue, 12 Jun 2007 12:05:29 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1Hy584-0008HI-AL; Tue, 12 Jun 2007 08:05:44 -0400 Date: Tue, 12 Jun 2007 12:05:00 -0000 From: Daniel Jacobowitz To: Robert Norton Cc: gdb@sourceware.org Subject: Re: Target Dependent Backtrace Termination Message-ID: <20070612120544.GA31806@caradoc.them.org> Mail-Followup-To: Robert Norton , gdb@sourceware.org References: <20070612112221.GC29495@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00096.txt.bz2 On Tue, Jun 12, 2007 at 04:56:57AM -0700, Robert Norton wrote: > I think this would be a good idea. I was certainly confused for a while > because of this, and given the recent discussion on this list about the > importance of unique frame IDs not having any for the outermost frame > seems like a bad idea. If you're not keen to add a field to struct > frame_id or change the signature of frame_this_id, perhaps > get_prev_frame_1 could be more eager about getting the frame id for the > prev frame then if it turns out to be null return null to indicate no > previous frame? This is how I assumed things would work given the > current interface. No, I think it would be wiser to do one of the other two ideas you mentioned. Minimizing unwinding is the central tenet of our current design, and it seems to work well (though we have room to do it better). -- Daniel Jacobowitz CodeSourcery