How does GDB/MI give the current frame

[Andrew Cagney]

>  > > For the CLI, something like this:
>  > > 
>  > > -> -interpreter cli "up"
>  > > <- ~"info on new frame..."
>  > > <- *select-frame,<frame-info>...
>  > > <- done

Note that the interpreter case is key, it lets the GUI respond to 
operations on the command line.

>  > > with similar for -stack-select-frame:
>  > > 
>  > > -> -stack-select-frame 1
>  > > <- *select-frame,<frame-info>,....
>  > > <- done
>  > > 
>  > > Where, yes, <frame-info> would be constructed by calling frame code.
>  > > 
>  > > -stack-info-frame would just be just:
>  > > 
>  > > -> -stack-info-frame
>  > > <- done,<frame-info>
>  > > 
>  > > The important thing is that, in both cases, the GUI is being driven by 
>  > > the select-frame event.
>  > > 
>  > 
>  > Cool !!
>  > 
>  > One thing:
>  > 
>  > -thread-select 2
>  > ^done,...
>  > -stack-select-frame 3
>  > ^done
>  > -thread-select 1
>  > ^done,..
>  > -thread-select 2
>  > ^done,..
>  > 
>  > If you would do "-stack-info-frame" now, you would notice that current
>  > stackframe for thread 2 is not longer frame 3 but frame 0 !!
>  > It this case would not it be appropriate to fire a "*select-frame" event.
> 
> There would still be problems with displaying the values of variables.
> Neither variable objects or the CLI command, display, seem to take
> notice of the thread number.

``bug'' in current MI protocol.  How would something like:

-thread 2 -<something else>
^done
-thread 2 -frame 3 -<something else>
-frame 3 -<something else>
^done

grab you?   ``-thread'' and ``-frame'' select the thread/frame for 
_just_ the period of that command.  They would not alter the CLI's 
selected thread/frame (the implementation would for the moment need to 
be a crock but thats a separate problem :-).

This would let the GUI manipulate frames independant of the CLI.

> Second thing:
> Playing with MI, I've notice in between -var-update|-var-delete|etc ..
> operation the frame selection level was reset to 0, failing the other operations
> that was still assuming a certain frame level.
> Now is this an appropriate behaviour? or a bug? if it is appropriate should
> client recall -stack-select-frame XX all the time to make sure things are ok

``bug''.  Actually major screwup in how GDB models threads (as in it 
doesn't really :-)

> How about to put the thread-id part ot the event ?

So the event would be ``selected changed'' and generated when both 
switching threads and frames?  If it is useful, ok.

Andrew