From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5825 invoked by alias); 12 Apr 2002 12:50:06 -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 5715 invoked from network); 12 Apr 2002 12:50:03 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 12 Apr 2002 12:50:03 -0000 Received: by fw-cam.cambridge.arm.com; id NAA00360; Fri, 12 Apr 2002 13:50:02 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma029620; Fri, 12 Apr 02 13:49:25 +0100 Received: from cam-mail2.cambridge.arm.com (localhost [127.0.0.1]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA05287; Fri, 12 Apr 2002 13:49:11 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA02782; Fri, 12 Apr 2002 13:49:23 +0100 (BST) Message-Id: <200204121249.NAA02782@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: gdb@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [rfc] frame->frame => frame->addr && frame->base() In-reply-to: Your message of "Thu, 11 Apr 2002 16:56:08 EDT." <3CB5F868.8070001@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Apr 2002 05:50:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-04/txt/msg00208.txt.bz2 > Hello, > > This comes from DanielB's and my discussion about dwarf2 CFA and > dwarf2's frame_base vs GDB's frame->frame. > > An executive summary is that the two dwarf2 frame concepts (CFA and > frame_base) do not go into one GDB frame (frame->frame). > > Because of this, I'd like to propose that the frame object have both: > > struct frame_info > { > ... > > // An ISA/ABI specific address within the ``specified frame'' that is > constant throughout the lifetime of the frame. This address is used by > GDB as a handle to identify this frame. This field must be initialized > as part of the creation of a frame object. (see dwarf2 CFA) > > CORE_ADDR addr; The main advantage of the DWARF CFA is that it is, as I understand it, precisely defined on all systems (something like: the value of the stack pointer when executing the first instruction of a function). As such, it will always be valid, and cannot change while executing the function. > // High level language concept of the base address of a frame. Often > refered to as ``frame_base'' or ``frame pointer''. This value should > only be computed on-demand. It is strongly recommended, though, that > implementations cache the computed value in the frame cache. The method > is initialized as part of the frame objects creation. The default > method returns frame->addr. (see dwarf2 DW_AT_frame_base) > > CORE_ADDR (*base) (struct frame_info *frame); What would this mean in the context of a function that doesn't use a frame pointer? What about a leaf function which doesn't store anything on the stack? I can't see how this can have any MI interpretation (other than the fact that all functions in a nested chain should have a different value). R.