Re: How does GDB/MI give the current frame

[Nick Roberts <nickrob@gnu.org>]

Andrew Cagney writes:
 > >  > >  > > -> -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.

In that case, I disagree strongly with the suggestion since I think that
"-interpreter-exec console" should only give quoted CLI output (plus prefix
character). I thought that was the whole idea as it allows front ends to keep
the console. Typing CLI input in directly currently gives a mixture of CLI/MI
output but this is fine as it is only a temporary/ad hoc means of accessing
the CLI. In Emacs, I will run commands from the console with
"-interpreter-exec console" and check the status of gdb with a set of MI
commands run behind the users back. I imagine a lot of others will do the
same, so please don't change this.

Earlier, you said

> with similar for -stack-select-frame:

> -> -stack-select-frame 1
> <- *select-frame,<frame-info>,....
> <- done

Can you elaborate? How does "*select-frame" get printed? Does it trigger
anything internally?

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

Yes, that sounds like a good idea. Is it easy to implement?

Nick