This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Frame handling


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]