From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25535 invoked by alias); 12 Feb 2004 18:59:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25450 invoked from network); 12 Feb 2004 18:58:59 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 12 Feb 2004 18:58:59 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i1CIwwnI008891 for ; Thu, 12 Feb 2004 19:58:58 +0100 Message-ID: <402BCCF2.601@axis.com> Date: Thu, 12 Feb 2004 18:59:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Re: CRIS port; frame cleanup crash References: <3F392591.4050409@redhat.com> In-Reply-To: <3F392591.4050409@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00322.txt.bz2 Ok, take two on trying to update the CRIS port to the new frame handling mechanism. I'm planning to hook in the DWARF CFI frame unwinder, but I don't know if that affects any of the other stuff I'm going to have to do. (I'm going to have to update to the new dummy stuff later, but I was hoping I could do that separately.) Thanks in advance for any answers to questions, or comments on what I've understood or misunderstood amongst all of this (or even pointers to information I might have missed). First of all, what does "unwind" mean in the frame context? I know it sounds silly, but I've been trying unsuccessfully to wrap my head around that word. Is there some fundamental thing I may have missed concerning the new frame handling, or can I just replace "unwind" with "dig out" in my head? About the struct unwind_cache: looking at the other architectures, I'm still not sure what I need in this struct. (I'm guessing stuff from the old struct frame_extra_info should go here if still needed.) Is there a recommended starting point for this struct? Some of the common members between architectures' unwind caches seem to be: prev_sp: Most comments say "The previous frame's inner most stack address. Used as this frame ID's stack_addr." So would that be the what the stack pointer was when the current frame was entered? base: Is this "base" as in "base for local variables" or does it refer to something else? Most architectures seem to set this to the frame's frame pointer. sp_offset and size I think I understand: how much the stack pointer has been changed so far in the frame, and how much stack space was allocated in this frame (absolute value of sp_offset) so far. Thanks, Orjan -- Orjan Friberg Axis Communications