Re: frame->unwind->this_base()

Daniel Jacobowitz
2003-03-18T16:38:10Z

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.