This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] frame->frame => frame->addr && frame->base()
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>, gdb at sources dot redhat dot com
- Date: Thu, 11 Apr 2002 15:29:36 -0700
- Subject: Re: [rfc] frame->frame => frame->addr && frame->base()
- References: <3CB5F868.email@example.com>
On Apr 11, 4:56pm, Andrew Cagney wrote:
> 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;
I like this. I find frame->frame confusing. Also, I like it that
you're documenting the fact that this value remains constant over the
lifetime of the frame. I think we have a number of targets which
don't get this right.
> // 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);
This translates the CFA (canonical frame address) into an address that's
useful for some other purpose, right? What are the purposes that it
would be used for?
(My worry is that there may be more than one translation which might
prove to be useful.)