Re: How does GDB/MI give the current frame

Andrew Cagney
2004-07-12T13:56:13Z

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