Re: [RFC] Prints the frame id when target stops

[Frederic RISS <frederic dot riss at st dot com>]

On Wed, 2007-01-17 at 17:17 -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 17, 2007 at 10:59:13PM +0100, FrÃdÃric Riss wrote:
> > Have you an idea how you would like the caching to work? Do you mean not
> > discarding the frame cache, or caching the returned string?
> 
> How much do we know about why it takes a long time?

Very good question :-) In Denis' case, he's using a JTAG link driven by
a probe which is in turn connected through ethernet to the workstation
where GDB is running.

I'm quite sure that the latencies at each memory access are what's
taking time, because the unwinding doesn't require any complex handling
other than retrieving the saved frame pointer (and there's no prolog
analysis going on). IIRC, -stack-list-frames was taking an average of
half a second to complete.

> For instance:
>   - We can speed up the psymtab lookup which currently shows up in
>     profiles.  A coworker of mine gave me some clever ideas on how
>     to do this if anyone wants to try it :-)

Hehe. What's the idea? maybe someone will pick it up.

>   - We can speed up prologue analyzers by judicious use of caching,
>     in a way that's completely reliable.  DWARF2 CFI is already pretty
>     speedy.
> 
> If these sorts of things are enough to help...
> 
> > Also, I don't see how we could have better checks within GDB than within
> > the frontend. The only reliable check is IMHO to compare frame ids after
> > steps and nexts.
> 
> I suspect you can only do this in stepi, really - step/next can end up
> in strange places...

... and end up in a frame with the same frame id? Seems unlikely, but
then GDB isn't the place where you'd want to trade accuracy for a very
small speedup.

Fred.