This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] frame->frame => frame->addr && frame->base()
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Fri, 12 Apr 2002 13:49:23 +0100
- Subject: Re: [rfc] frame->frame => frame->addr && frame->base()
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> 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.