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

[Vladimir Prus <ghost@cs.msu.su>]

On Thursday 18 January 2007 00:59, Frédéric Riss wrote:
> 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.

No, I don't have the slightest inclination to touch that.

> 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.

Or introduce 'struct cached_result_of_stack_list_frames' that
can contain whatever I like and which can be conveniently edited.

You've actually pointed a nice problem -- if frontend avoid -stack-list-frames
when frame id did not change, it will have stale address of the top frame too.

> 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.

GDB always knows that it does a step. A frontend might be sending
a command typed by the user, and that might be user-defined command,
and there's no way to tell if there's step in that command.

> 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.

I think there are some simple optimizations we might make.

- Volodya