From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32568 invoked by alias); 12 Jun 2007 11:57:34 -0000 Received: (qmail 32559 invoked by uid 22791); 12 Jun 2007 11:57:33 -0000 X-Spam-Check-By: sourceware.org Received: from mms2.broadcom.com (HELO mms2.broadcom.com) (216.31.210.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Jun 2007 11:57:29 +0000 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 12 Jun 2007 04:57:19 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 743BA2AF; Tue, 12 Jun 2007 04:57:19 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 608C72AE; Tue, 12 Jun 2007 04:57:19 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FJJ15553; Tue, 12 Jun 2007 04:57:19 -0700 (PDT) Received: from NT-IRVA-0752.brcm.ad.broadcom.com ( nt-irva-0752.brcm.ad.broadcom.com [10.8.194.67]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 31D0A69CA5; Tue, 12 Jun 2007 04:57:19 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Target Dependent Backtrace Termination Date: Tue, 12 Jun 2007 11:57:00 -0000 Message-ID: In-Reply-To: <20070612112221.GC29495@caradoc.them.org> References: <20070612112221.GC29495@caradoc.them.org> From: "Robert Norton" To: "Daniel Jacobowitz" cc: gdb@sourceware.org X-WSS-ID: 6A7055953CG9018029-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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/msg00095.txt.bz2 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz > Sent: 12 June 2007 12:22 > To: Robert Norton > Cc: gdb@sourceware.org > Subject: Re: Target Dependent Backtrace Termination >=20 > On Tue, Jun 12, 2007 at 02:23:11AM -0700, Robert Norton wrote: > > to go one too far! Looking at some other ports it seems that the > > solution is to return the null frame id for the outermost frame thus > > causing get_prev_frame_1 to return null and terminating the=20 > backtrace. >=20 > Right. OK. Thanks for the response. I just assumed I must be doing something wrong since it is an anomaly in what is otherwise a relatively clean API! =20 > > But this means that the outermost frame doesn't haven't a=20 > valid frame > > id! Won't this cause problems? Am I missing something rather > > fundamental? >=20 > Also right. We've been talking on and off about changing this, so > that an unwinder can indicate "this is marked as the last frame" > separately from "I don't know what this frame's ID is". If we manage > to do that, I hope we can require all frames to have a valid ID. > No one's done it yet, though. 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. Cheers, Robert =20 > --=20 > Daniel Jacobowitz > CodeSourcery >=20 >=20