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

[Frédéric Riss <frederic dot riss at gmail dot com>]

Le jeudi 18 janvier 2007 Ã 00:37 +0300, Vladimir Prus a Ãcrit :
> >> It actually won't. If -stack-list-frames is changed to return cached
> >> result when it's absolutely clear that the stack did not change, you
> >> have no behaviour change, just better performance.
> > 
> > Unforunately, making absolutely sure the stack did not change may not
> > be possible.
> 
> Are you sure? For example, if the only command since previous 
> -stack-list-frames was -exec-step, then the stack is the same.
> 
> For the cases where we're not sure, gdb can discard cached value
> and produce new.
> 
> The thing is, if the frontend tries to compare old frame id to
> new frame id, and skip -stack-list-frames if they are equal,
> it's not going to be any more reliable than doing similar check
> in gdb. And in gdb, we can have better checks.

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?

If you want the first approach (keep the frame cache), then this is
quite an intrusive change. It would also require keeping a frame cache
per-thread and not as a global like it's done now.

If you just want to cache the result of -stack-list-frames, then you'd
have to edit out the addr field which contains the frame's PC for the
top frame... not very nice.

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. Any other execution control command requires to
re-unwind the whole stack. This check seems to be as reliable in the
frontend as in GDB.

I agree with your point though: making -stack-list-frames as fast as
possible would benefit all frontends. However, it seems hard to modify
GDB's frame handling to handle that correctly.

Fred.