From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3534 invoked by alias); 24 Jan 2006 22:52:31 -0000 Received: (qmail 3525 invoked by uid 22791); 24 Jan 2006 22:52:31 -0000 X-Spam-Check-By: sourceware.org Received: from mail.emacinc.com (HELO mail.emacinc.com) (208.248.202.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jan 2006 22:52:30 +0000 Received: from emac77.emacinc.com ([208.248.202.77] helo=eng011.emacinc.com) by mail.emacinc.com with esmtp (Exim 4.50) id 1F1X1P-0006To-SG for gdb-patches@sourceware.org; Tue, 24 Jan 2006 16:52:22 -0600 From: NZG To: gdb-patches@sourceware.org Date: Tue, 24 Jan 2006 22:52:00 -0000 User-Agent: KMail/1.8.2 References: <200601241629.32011.ngustavson@emacinc.com> In-Reply-To: <200601241629.32011.ngustavson@emacinc.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200601241651.16514.ngustavson@emacinc.com> X-SA-Exim-Connect-IP: 208.248.202.77 X-SA-Exim-Mail-From: ngustavson@emacinc.com Subject: Re: request for structure documentation Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Relay: X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00390.txt.bz2 A more specific question: My code appears to be fixable by either causing the architecture specific unwind code to return null in frame 0, or by allowing unwind to occur here, but then setting the id to invalid on the unwound frame, thus preventing it from printing and stopping the chain of get_prev_frames. But which is correct? This seems unclear from the comments thx, NZG On Tuesday 24 January 2006 4:29 pm, NZG wrote: > get_prev_register appears to depend on the value of frame_unwind->this_id, > but I can't find any documentation for what this element represents. > Could somebody point me to some documentation or elaborate a bit? > > struct frame_unwind > { > /* The frame's type. Should this instead be a collection of > predicates that test the frame for various attributes? */ > enum frame_type type; > /* Should an attribute indicating the frame's address-in-block go > here? */ > frame_this_id_ftype *this_id; > frame_prev_register_ftype *prev_register; > }; > > > thx, > NZG