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

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

Mark Kettenis wrote:

>> From: Vladimir Prus <ghost@cs.msu.su>
>> Date: Wed, 17 Jan 2007 02:34:34 +0300
>> 
>> On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
>> >  > > We'd like to avoid refreshing the thread and the frame view when
>> >  > > the user perform a step (or a next) and when the program stops in
>> >  > > the same thread
>> >  > > and in the same frame.  In the stop reason we got the current
>> >  > > thread id,
>> >  > > but we are missing something to identify the frame.  That patch
>> >  > > lets gdb emits on the MI output a string that could be used to
>> >  > > easily identify the
>> >  > > current frame.  If you are ok with this approach then I'll update
>> >  > > the testsuite.
>> >  > 
>> >  > Would not a better approach be to modify -stack-list-frames and
>> >  > friends, so that they check frame id internally, and it has not
>> >  > changed, just return the same result? Such approach will uniformly
>> >  > help all frontends, and won't expose new concepts in the interface.
>> > 
>> > It would change the behviour of those commands but I guess it could be
>> > added as an option.
>> 
>> 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.

- Volodya