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

[Kevin Buettner <kevinb@redhat.com>]

On Apr 12,  9:38am, Andrew Cagney wrote:

> >> // 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).
> 
> The value is debug-info dependant.  See section 3.3.5 of the dwarf2 
> spec.  For some frames this value may not even be applicable - that is 
> ok because it isn't a requirement of a frame.

If the value returned by frame->base() is debug-info dependent, then
that would suggest that it could have different values for different
types of debug info.  That in turn suggests that you have to know what
type of debug info you're dealing with at frame creation time so that
frame->base can be initialized correctly.

Of course, it could be done lazily.  You could just initialize frame->base
to lazy_base() (or whatever).  lazy_base() would determine the function
that's really required for that frame + debug info, reset the ->base
field, and then invoke the function it's just calculated to obtain the
desired value.

Implementation details aside, this dependency causes me to wonder if it's
really a good idea make this operation a member of the frame struct.

Kevin