Re: frame->unwind->this_base()

Daniel Jacobowitz
2003-03-17T17:11:46Z

On Mon, Mar 17, 2003 at 11:56:40AM -0500, Andrew Cagney wrote:
> >On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>>However, shouldn't the only thing needing the `virtual frame pointer' /
> >>>>get_frame_base() be the code that needs a virtual base pointer when
> >>>>computing the value of a local variable?
> >
> >>>
> >>>
> >>>Yes, and that's the only time that we search for the frame base. But
> >>>what difference does it make?
> >
> >>
> >>(gdb) info frame
> >>
> >>will display the correct value.
> >
> >
> >What does "correct" mean though?
>
> Display the frame's `virtual base pointer'.
>
> >>>At that point we have an offset that we
> >>>know is relative to DW_AT_frame_base, but we don't know if it's
> >>>relative to what the rest of GDB considers the frame base (since we
> >>>never use DW_AT_frame_base to compute the frame base in the first
> >>>place; and it's not clear to me that we should be).
> >
> >>
> >>Where, apart from `info frame', and variable evaluation, is it correct
> >>for GDB to use the frame base?
> >
> >
> >I'm sorry, but I just don't understand what you're asking. We use the
> >frame base all over.
> >
> >The current frame base (i.e. id.base) is produced by target specific
> >code - often via prologue analysis; on x86-64 via CFI; etc.
>
> Er,
>
> >GDB's frame code also makes available the get_frame_base() method. While
> >the default implementation returns get_frame_id().base, I think there is
> >going to need to be a per-frame frame->unwind->this_base method.
>
> get_frame_base() returns ->frame and NOT ->id.base.

OK, I'm definitely going around in confused little circles. Don't the
two statements above disagree? The current get_frame_base does return
->frame but you also say above that get_frame_base should return
get_frame_id().base.

Conceptually, are frame->frame and frame->id.base supposed to be the
same?