Re: [rfc] frame->frame => frame->addr && frame->base()

[Richard Earnshaw <rearnsha@arm.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.