From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13727 invoked by alias); 12 Feb 2004 20:06:58 -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 13701 invoked from network); 12 Feb 2004 20:06:57 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 12 Feb 2004 20:06:57 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7E9A32B92; Thu, 12 Feb 2004 15:06:55 -0500 (EST) Message-ID: <402BDCDF.5040506@gnu.org> Date: Thu, 12 Feb 2004 20:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: CRIS port; frame cleanup crash References: <3F392591.4050409@redhat.com> <402BCCF2.601@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00325.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.) CRIS is already using generic dummy frames so it should be in good shape. The only potential got-ya is with unwind_dummy_id - you'll need to check that the correct ID is returned. > 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? The term "unwind" is used by the dwarf-2 specification. http://www.eagercon.com/dwarf/dwarf3std.htm it includes a working example in the appendix. The important thing is to "dig out" the register from the correct frame. frame_unwind_register (next_frame, "pc") will "dig out" the PC from the next frame (often found in next frame's link register) returning the value as it should be in "this_frame". > 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: Yes, frame_extra_info is a very good starting point. "init_saved_regs" is also a very a good starting point for the new cache init code. > 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? Probably :-( The i386 call instruction adjusts the SP leading to: /* Now that we have the base address for the stack frame we can calculate the value of %esp in the calling frame. */ cache->saved_sp = cache->base + 8; > 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. Thats correct. > 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. that's correct Also: struct trad_frame_saved_reg *saved_regs; (from mips et.al.) which can help simplify the implementation of register unwind. Andrew