This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: How does GDB/MI give the current frame
> > > > -> -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