Re: frame->unwind->this_base()

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Mar 18, 2003 at 09:54:29AM -0500, Andrew Cagney wrote:
> >
> >So in this case should we be hooking the get_frame_base() call to
> >return the computed DW_AT_frame_base?  [...]  And what happens if we don't 
> >have DWARF-2
> >information?
> 
> At the start I wrote:
> 
> > For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> frames, it would return an attempt at an equivalent value.  Hopefully it 
> wouldn't be called for other frame types :-).

OK.  I'll make the assumption that the DW_AT_frame_base and the CFA in
the dwarf2 unwind information (if both present) will agree.  If they
don't, well... we'll have to deal with that later.

> A better question is, what about other debug types?  The definition of 
> the frame-base is dependant on the debug info.
> 
> Dig dig.  Other debug info (e.g., LOC_LOCAL) depends on 
> FRAME_LOCALS_ADDRESS().  So to take this a step further, it is a merged 
> FRAME_LOCALS_ADDRESS() + get_frame_base() that is needs to become per frame.
> 
> > If so, we're going to need to go
> > through all the uses and computations of the frame base in all targets
> > for consistency.
> 
> All existing calls to get_frame_base() in core-gdb need to be audited 
> anyway :-(  This is so that breakage such as VALUE_FRAME() can finally 
> be laid to rest (see "frame.h", "frame ID" for why get_frame_base() 
> isn't up to the task).

Yep.  Thanks for holding my hand through this; I think I'm back on the
same page now.  I agree that eventually the business with evaluating
the DW_AT_frame_base should be reduced to a get_frame_base call,
although it may be... a little while.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer