From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13401 invoked by alias); 1 Jul 2003 13:02:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13390 invoked from network); 1 Jul 2003 13:02:04 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 1 Jul 2003 13:02:04 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 204402B78; Tue, 1 Jul 2003 09:02:03 -0400 (EDT) Message-ID: <3F01864B.6070403@redhat.com> Date: Tue, 01 Jul 2003 13:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jafa Cc: gdb@sources.redhat.com Subject: Re: Frame handling References: <00cd01c33f8d$b4e570e0$0a00a8c0@nkelseyhome> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00013.txt.bz2 > Out of interest, what is the theory behind the frame id being made up of > address + func? From the definition of frame ID: /* The frame object's ID. This provides a per-frame unique identifier that can be used to relocate a `struct frame_info' after a target resume or a frame cache destruct. It of course assumes that the inferior hasn't unwound the stack past that frame. */ struct frame_id { /* The frame's stack address. This shall be constant through out the lifetime of a frame. Note that this requirement applies to not just the function body, but also the prologue and (in theory at least) the epilogue. Since that value needs to fall either on the boundary, or within the frame's address range, the frame's outer-most address (the inner-most address of the previous frame) is used. Watch out for all the legacy targets that still use the function pointer register or stack pointer register. They are wrong. */ /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two frame bases. This will need to be expanded to accomodate that. */ CORE_ADDR stack_addr; /* The frame's code address. This shall be constant through out the lifetime of the frame. While the PC (a.k.a. resume address) changes as the function is executed, this code address cannot. Typically, it is set to the address of the entry point of the frame's function (as returned by frame_func_unwind(). */ CORE_ADDR code_addr; }; /* Methods for constructing and comparing Frame IDs. NOTE: Given frameless functions A and B, where A calls B (and hence B is inner-to A). The relationships: !eq(A,B); !eq(B,A); !inner(A,B); !inner(B,A); all hold. This is because, while B is inner to A, B is not strictly inner to A (being frameless, they have the same .base value). */