From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10300 invoked by alias); 12 Apr 2002 21:59:29 -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 10221 invoked from network); 12 Apr 2002 21:59:28 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 12 Apr 2002 21:59:28 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 98AD25EA11; Fri, 12 Apr 2002 16:59:27 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [rfc] frame->frame => frame->addr && frame->base() References: <3CB5F868.8070001@cygnus.com> From: Jim Blandy Date: Fri, 12 Apr 2002 14:59:00 -0000 In-Reply-To: <3CB5F868.8070001@cygnus.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00220.txt.bz2 Andrew Cagney writes: > 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; If this needs to be equal to the Dwarf 2 CFA value, it seems to me the comment should say that explicitly. Of course the explanation shouldn't be specific to any debug format, but it should relate its meaning to various interesting debug formats; see my suggested text below. > // 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); Same here --- I think the comment needs to be more explicit on what this function's value must mean. For example: Function that returns the frame's base address, for local variable references. Most debug info formats describe the locations of stack-based local variables as offsets from some assumed base address; exactly what that base address is (frame pointer register? stack pointer?) varies from machine to machine. Whatever the case, this function computes that base address. For Dwarf 2, the base address is the value given by the function's DW_AT_frame_base attribute, and the value that the DW_OP_fbreg instruction pushes; for STABS, the value of an N_LSYM stab is the offset from this base address to the variable.