Re: frame->unwind->this_base()

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Mar 17, 2003 at 08:05:58PM -0500, Andrew Cagney wrote:
> >On Mon, Mar 17, 2003 at 01:20:28PM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>>>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?
> >
> >>
> >>No.  See get_prev_frame() where it is defaulting ->frame to ->id.base.
> >>
> >
> >>> The current get_frame_base does return
> >>>->frame but you also say above that get_frame_base should return
> >>>get_frame_id().base.
> >
> >>
> >>No.  Default to get_frame_id().base.
> >
> >
> >So is that supposed to be a statement about the future in the first
> >paragraph?  It's sure not worded as one, no wonder I'm confused.
> 
> The present.  GDB historically has had FRAME_FP and frame->frame and 
> their intended purposes were overloaded: per frame unique identifier, 
> frame base pointer, ...
> 
> Frame ID provides a per-frame unique identifier.
> 
> >>>Conceptually, are frame->frame and frame->id.base supposed to be the
> >>>same?
> >
> >>
> >>No?
> >
> >
> >Then could you enlighten me as to what the difference is supposed to
> >be?
> 
> For dwarf2, check the spec where it discuss CFA (see CFI) and frame-base 
> (see 3.3.5).
> 
> CFA + &function == frame_id
> A per frame unique identifier that must be constant through out the 
> lifetime of the frame.  CFI recommends the top-of-stack from the 
> previous frame.
> 
> frame-base == get_frame_base()
> What ever the debug info would like it to be.   The ISAs ABI will 
> provide a strong set of guidelines though (if, for a framed function it 
> doesn't match what the user expects, the'll likely complain :-).  It 
> will often point into the middle of the stack frame.

So in this case should we be hooking the get_frame_base() call to
return the computed DW_AT_frame_base?  If so, we're going to need to go
through all the uses and computations of the frame base in all targets
for consistency.  And what happens if we don't have DWARF-2
information?

I guess I just don't see how this evolves.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer