Re: Frame handling

Daniel Jacobowitz
2003-07-01T14:09:41Z

On Tue, Jul 01, 2003 at 08:58:46AM -0400, Andrew Cagney wrote:
> >>>>Question - reading through this again I think the goal of call these
> >>>>functions is to work with the current frame and the function get passed
> >>>>the
> >>>>child frame so they can do a backtrace if it hasn't already been
> >>>>done... why
> >>>>not call a function to do a 1 level backtrace and then eliminate the
> >>>>next_frame parameter? It would recduce confusion and most ports will
> >>>>have an
> >>>>internal unwind function anyway.
> >
> >
> >>
> >>>Question - reading through this again I think the goal of call these
> >>>functions is to work with the current frame and the function get passed
> >>>the
> >>>child frame so they can do a backtrace if it hasn't already been done...
> >>>why
> >>>not call a function to do a 1 level backtrace and then eliminate the
> >>>next_frame parameter? It would recduce confusion and most ports will
> >>>have an
> >>>internal unwind function anyway.
> >
> >>
> >>I'm not sure I understand the question.
>
> >I agree, and I don't think it will make much difference eitehr way, however
> >I was just thinking that it would be a whole lot easier to explain these
> >functions...
> >
>
> Um, this is still dangling. Can you please express your question using
> terminology consistent with the frame unwind code.

I think Nick's question is: why does every architecture implement the
cache lazily, instead of GDB instructing the architecture when to
create the cache.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer