How does GDB/MI give the current frame

[Andrew Cagney]

>  > >  > > -> -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.
> 
> On my gdb, -interpreter-exec cli "up" gives:
> 
> ^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\""
> (gdb) 
> 
> I'm still lost here.

Sorry s/cli/console/, teach me to write something from memory.

>  > > 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
> 
> Or values could be printed for all threads:
> 
> -var-evaluate-expression var1
> ^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...]
> 
> and likewise for other mi commands. This would have the disadvantage of
> breaking existing behaviour but I imagine a user might want to see the value
> of a variable across all threads and would not wish to create a variable
> object for each thread.

For existing commands, I don't get warm fuzzies.  Assuming that the GUI 
is only displaying one thread, there's no need to supply the value 
across all threads.

As an extension, I guess, why not.  Something like:

-thread-apply 1 2 3 4 -- -something
^done,result=[{thread-id="1",result=<result>},{thread-id="2",error=<something>},...]

or

-thread-apply * -- -something
^done,result=[{thread-id="1",result=...},...]

that is, it returns a list of results from each individual command - 
that makes more sense.

Andrew